Databases & data engineering
Whether you are starting from nothing or from a database somebody else built and left behind. Get the data model right and the rest of the project gets cheaper; get it wrong and you pay for it forever.
Typical work
- Design from scratch. Tables, relationships, constraints and indexes designed around the questions you will actually ask of the data.
- Take over a database you already have. The developer has left, nobody is sure what half the tables mean, and everyone is afraid to touch it. We read it, document every table and relationship, repair what is broken, and hand you back a system that is safe to change — without starting again.
- Reconnect what you already have. A dashboard, a portal or new reporting put on top of your existing database rather than replacing it, and joined up with the other systems it should have been talking to all along. Often this is all that is needed.
- Move off something you have outgrown. An old Access file, an abandoned application, a system whose licence keeps rising — migrated into something current, with every year of history carried across and nothing left behind.
- Escape from spreadsheets. Moving years of Excel into a real database without losing history — including the messy rows.
- Make it fast again. Finding the queries that cost you minutes a day and rewriting them, plus the indexes nobody added.
- Pipelines. Scheduled jobs that collect, clean, join and load data from files, portals and other systems — with alerts when a run fails.
- Dashboards and reporting. The numbers your team rebuilds by hand each week, produced automatically and refreshed on a schedule.
- Safety net. Automated backups, tested restores, and roles so not everyone can delete everything.
Why a generic schema will not do
Two businesses in the same trade ask different questions of the same data, and the schema has to be designed around your questions. Get it generic and every report afterwards becomes a workaround — which is how an off-the-shelf system ends up with fourteen spreadsheets around it.
From a paper archive to data you can question
Most of what we are asked for is not one of these services on its own. It is the whole path: the records are on paper or in twenty spreadsheets, new ones arrive every day, and nobody can answer a question about last year without someone walking to a shelf. We build all four parts of the way out, as one system, so nothing is handed between people who never speak.
Design the database
Tables, relationships and constraints built around the questions you will actually ask — not around the shape of the paper form. Decided before anything is typed, because this is what everything later depends on.
Digitise what you already have
Years of binders, files and spreadsheets turned into structured records. Every page is scanned and kept, linked to its row, so the original is always one click away when someone questions a number.
A way in for new records
A portal your team uses instead of the paper form — on a desk, or a phone at the machine. Bulk import for the spreadsheets you already keep. Designed around what the person entering it already has in their hand, because a form slower than the paper it replaces gets abandoned.
A dashboard, with the right people seeing the right things
Search, filter and export across everything. The reports someone currently rebuilds by hand. And commercially sensitive figures — costs, margins, per-line performance — enforced in the database so they are visible only to whoever you decide, not merely hidden on screen.
Common in manufacturing, laboratories, clinics and schools — anywhere records were kept faithfully for years by people who now cannot get anything back out of them. It is usually phased: the database and one record type first, proving the shape on real data before the rest of the archive is touched.
How it starts. Not with a quote. A short paid review — we look at your actual forms, count what is there, time a sample so the estimate is measured rather than guessed, and write you a phased plan with real numbers. The fee comes off the build if you go ahead, and the document is yours either way.
The demo runs on invented data. Switch it between a paper converter, a school and an accounting practice, and between owner and supervisor, to see the same system fit a different business.
What you get
You get
Schema diagram, migration scripts, seed data, a backup plan, and written documentation of every table.
Usual engines
PostgreSQL, MySQL / MariaDB, SQL Server, SQLite, Supabase.
Good fit when
Two people disagree about which file is the current one, a report takes someone a whole morning, or you have a database nobody left behind an explanation for.
Typical timeline
One to three weeks for design and migration on a single-system project.
Not sure this is the right one?
Describe the problem instead of the solution. A short call is usually enough to tell whether it is this, something else, or nothing you should spend money on.
Book a free callWork of this kind
Client names withheld on request — the problems and the shape of the solutions are real.
Accounting · Automation
Every new document, on the right desk by morning
A program that checks a government tax portal for hundreds of clients every day, files what is new in a database, notifies the employee who handles that client, and sends the manager one report each morning.
Education · Platform & back end
Python in seconde, taught by teachers who are not programmers
Crescendo Academy: students write and run Python in the browser, the teacher follows a guided path rather than improvising code, and the school can see every change — including one made to an exam question after submissions came in.
Research · Data & analysis
Research data that behaves like a record, not a folder
Our own build, and the one you can click: samples followed from intake to figure, runs tracked by instrument and reagent lot, and the analysis itself on screen — an expression heatmap and a genome-wide association view.
WhatsApp +1 514 889 1557
Monday–Friday, 9:00–18:00 (Montreal time)
