Solutions · Production Hardening · Alberta

You Built It. Now It Has to Hold.

You built a working application yourself — Lovable, Replit, Bolt, Cursor, Claude Code — and it does the thing. Running a business on it is a different job: real customers, real money, real data, and no way to change it safely. That second job is the one we do.

Book a 30-Minute Call See the work

First, the part nobody says

Building It Yourself Was the Right Call.

Two years ago, finding out whether a piece of software would actually help your business meant a discovery engagement and a five-figure cheque before anyone typed a line. You skipped that. You built the thing, put it in front of real users, and learned in a fortnight what a specification would have guessed at over a quarter.

That is not a shortcut, it is a better order of operations — and it leaves you in a much stronger position than the buyer who is still trying to describe what they want. You already know what the software has to do, because you have watched people use it.

What you have now is a prototype that earned a real build. The gap between the two is not talent and it is not effort — it is a specific, finite, unglamorous list of things that only matter once other people's data, money and trust are involved. Here is that list, plainly.

What actually breaks

It Works on the Demo. Then It Meets Customers.

These are the six we find most often, in roughly the order they cost you something. If you recognise two or three of them, that is the normal starting condition rather than a bad sign.

Anyone can read anyone's data

The login works, so it feels secure. But authentication is not authorisation — the check that says this user may see this record is a separate thing, and in a generated app it is usually enforced on the screen rather than in the query. The bug is invisible until the wrong customer sees the wrong invoice.

The database has no history

Schema changes were made by asking for them, so there are no migrations. That means no repeatable path from an empty database to the current one, no safe way to change a table with live data in it, and no way to set up a second environment to test anything.

Secrets are in the code

API keys, database URLs and provider tokens end up committed, pasted into the client bundle, or shared across environments. Anything in the browser bundle is public, and a leaked key is a bill and a breach at the same time.

Money and state disagree

A payment succeeds and the order does not update, or a webhook arrives twice and the customer is charged twice. Payment state has to be reconciled against the provider rather than inferred from what the user's browser did, and that is rarely how a first version works.

Nothing is backed up, nothing is watched

No tested restore, no error tracking, no uptime alerting. The first you hear about an outage is a customer phoning, and the first you hear about data loss is when someone needs the data.

Nobody can change it safely

There are no tests, so every change is a gamble on a codebase that got large fast. This is the point most owners actually notice: not a crash, but the day they stop being able to add anything without breaking something else.

Three possible answers

One of These Is True About Your Build.

The assessment ends in one of three verdicts, with a costed plan against whichever one it is. We publish all three because a firm whose only possible answer is "yes, we can fix it" is not assessing anything.

Harden it

The bones are sound

The data model is broadly right and the product decisions were good ones. We fix authorisation, add migrations and tests, move secrets, make payments reliable, put backups and monitoring in place, and get it deployable without drama. The thing you built stays the thing you run.

Rebuild the core

The interface is right, the foundation is not

This is the most common verdict. Everything you learned about the workflow was worth the build — but the data model or the tenancy design will not survive growth. We keep the product thinking and the screens, and rebuild what sits underneath, in phases, while it stays live.

Start over

The prototype did its job by proving the idea

Sometimes the fastest path is a clean build informed by everything the prototype taught you. We will say so directly, and we will say it at the assessment rather than after three months of billable repairs. It is not the answer we are hoping for, and it is not rare either.

What the work is

Unglamorous, Finite, and the Whole Job.

Authorisation enforced at the data layer

Every read and write scoped to the user and the tenant that owns it, checked in the query rather than hidden on the screen. This is the first thing we look at and the most common serious defect we find.

A real schema, with migrations

Version-controlled migrations, constraints and indexes, so the database can change safely with live data in it and a second environment can be created on demand instead of by hand.

Secrets, environments and access

Keys out of the code and out of the browser bundle, separate development and production environments, rotation that does not require an outage, and a record of who can reach what.

Payments and webhooks that survive reality

Idempotent handlers, signature verification, retries, and state reconciled against the payment provider — because webhooks arrive twice, arrive late, and arrive while you are deploying.

Backups, monitoring and a tested restore

Automated backups you have actually restored from once, error tracking, uptime alerting and logs that make an incident diagnosable. A backup nobody has restored is a theory.

Enough tests to change things

Not full coverage — coverage on the paths where being wrong is expensive, so the next change is a routine deployment rather than a gamble on a codebase nobody has read end to end.

Performance under real data

The queries that were fine with forty rows and fall over at forty thousand, found and fixed before your customers find them for you.

Ownership you can prove

Your own repository, your own cloud accounts, your own domains and keys, and documentation written for the next developer — including one who is not us.

How the engagement runs

Assessment First. Then a Costed Plan.

We read the code and the running system against a fixed scope and hand you a written report: what is wrong, ranked by severity, with a costed plan for each of the three verdicts. It is paid work and the report is yours — including the freedom to take it to another firm or to your own developer.

If you go ahead, the fixes are phased with the most dangerous defect first, which is almost always authorisation. Everything lands in your repository and your cloud accounts as it is done, so you are never holding a system you cannot take elsewhere.

Where the scope stops

We will not tell you the prototype was a mistake. Building it is how you learned what the software has to do, and that knowledge is worth more than the code either way.
We do not quote a fixed price before reading the code. A paid assessment comes first, you own the report, and you are free to hand it to another firm or to your own developer.
We do not take over a codebase and make you dependent on us. Everything lands in your repository and your accounts, documented for whoever comes next.
We do not rescue a project whose real problem is that nobody wants the product. Software engineering cannot fix that, and we will say so rather than bill for it.

Relevant proof · our own product

Quote → paid

QuotingAI · AltaPro AI's own product, not client proof

QuotingAI is the clearest example we can show you of this exact path, because we walked it on our own codebase. A quoting pattern that had worked in client builds became a live multi-tenant SaaS — and the work that turned it into one is the work on this page. Tenancy enforced at the data layer rather than trusted to each caller, because the interesting leak is never the obvious query: it is the report, the export, the background job or the webhook handler where a missing filter silently crosses a boundary. Payment state reconciled against Stripe rather than inferred from the user's journey, because a proposal marked paid that is not, and a deposit taken against an unsigned quote, are both unacceptable in different directions.

Listed as our own software rather than mixed in with client results, and labelled that way everywhere it appears on this site.

Read the QuotingAI build All case studies

Common questions

Prototype to Production, Answered.

What Does the Assessment Actually Cover?

A fixed-scope read of the codebase and the running system: authorisation and data isolation, the data model and how it will age, secrets and environment handling, payment and webhook correctness, backups and monitoring, dependency and deployment risk, and the performance profile under realistic data. You get a written report with issues ranked by severity and a costed plan for each of the three possible verdicts. The report is yours — take it to another firm if you want to.

Which Tools Do You Work With?

Applications built with Lovable, Replit, Bolt, v0, Cursor, Claude Code, Windsurf, or any combination of them and hand-written code. What matters is what the code does, not what generated it. In practice most of what we see is a React or Next.js front end with a hosted database behind it, which is familiar ground.

Will You Tell Us to Throw It Away?

Sometimes, and we will say it at the assessment rather than after three months of billable repairs. More often the verdict is in the middle: the product thinking and the screens are worth keeping and the foundation underneath them is not. We will show you the reasoning either way, in the report you paid for and own.

Can You Work With the Person Who Built It?

Usually the best arrangement there is. An owner or an internal builder who knows exactly what the software is for, paired with engineers who handle the parts that are unforgiving, produces better software than either alone — and it keeps the product knowledge inside your business rather than moving it to ours.

How Much Does It Cost to Get to Production?

It depends on the verdict, which is the honest answer and the reason the assessment comes first. What we can tell you before we start is the shape: hardening is phased, the most dangerous defect is fixed first, and you are given a costed plan before any build work begins rather than an open-ended engagement.

Can You Keep It Running Afterwards?

If you want us to. Ongoing operation, monitoring and development is a normal arrangement, and so is handing it over documented so your own developer or a future hire can take it. The code and the accounts are yours in both cases; that is not contingent on keeping us.

Book a 30-Minute Call.

Show us what you built and what it has to survive. 30 minutes, no commitment, and an honest first read on which of the three verdicts you are probably looking at.

Book a 30-Minute Call Contact us

Edmonton, Alberta · No commitment · 587-937-6948

Up a level

All Solutions

The four things we build for Alberta operators, in one place.