From prototype to production: what changes when you ship

You've seen the demo. The tool reads invoices, extracts the numbers, and files them automatically. It works. Your team is excited. Now comes the question: how do you actually ship this.

The gap between a prototype and a product is not small. It's where most founders get surprised.

What a prototype actually proves

A prototype shows that the core idea is sound. You feed it clean data under controlled conditions, and it does what you built it to do. That's valuable. It means you're not chasing something impossible.

But a prototype lives in a lab. It handles the happy path. It works on the 50 invoices you tested it with, formatted the way your accountant formats them, in English, with no smudges or handwriting.

A product lives in the real world.

The work that happens between prototype and production

Here's what changes.

Data safety and ownership. In a prototype, data might live anywhere—a shared folder, a vendor's servers, a notebook. In production, your data has to be yours. That means deciding where it lives, who can see it, how long you keep it, and what happens if something goes wrong. A dental clinic in Kelowna can't have patient records floating around a third-party server. A distributor in Calgary needs to know exactly where their pricing data sits and who has access.

This is not optional. It's the difference between legal and not legal. It's also the difference between a tool you own and a tool that owns you.

Error handling. A prototype fails loudly and stops. A production tool fails quietly and keeps working, or fails in a way that a person can understand and fix. When an invoice doesn't parse, what happens next. Does the system skip it silently. Does it queue it for a human to review. Does it send an alert. You have to decide, and then build it.

A 12-person software company in Gastown can't have their billing system silently lose half their invoices. A plumber in Richmond can't have their job quotes disappear because the system didn't know how to handle a handwritten note on the back.

Scaling and monitoring. A prototype handles one job at a time. Production means handling 100 jobs, or 1,000, without slowing down. It means knowing when something is broken before your customer does. It means having a way to see what the tool is doing, why it made a decision, and whether it's drifting off track.

A property manager in Surrey might process 5 tenant applications a week. A prototype can handle that in seconds. But what if they scale to 50 a week. What if the tool starts making mistakes. You need visibility and control.

Training and handoff. Your team has to use this thing. That means documentation, training, and often a period where someone who built it is standing over someone's shoulder saying "no, click that one." A prototype is a solo project. Production is a team sport.

Keeping ownership. This is the one nobody talks about until it's too late. If you build on a vendor's platform, you don't own the result. You're renting it. If the vendor changes their terms, raises their prices, or goes out of business, you're stuck. If you want to move to a different tool, you lose everything.

Ownership means the code and data are yours. You can see how it works. You can change it. You can move it. You can stop paying and keep using it. This is not free, but it's the price of control.

The timeline

A prototype takes 2 to 4 weeks. It's focused and small. You're proving the idea, not building for production.

Moving from prototype to production takes another 4 to 8 weeks. That's where you add security, error handling, monitoring, documentation, and training. That's where you make sure the data is yours and stays safe. That's where you make sure your team can use it without you.

Some of that work is visible. Some of it is invisible. All of it matters.

What to build first

Don't try to build the perfect product on day one. Build the smallest thing that solves a real problem for a real person on your team. Use it. Break it. Fix it. Then expand.

An accounting firm in Burnaby might start by automating one type of invoice, for one client, with one person using it. Once that's solid, they expand to other invoice types and other people. A property manager might start by automating tenant screening for one property type, then expand.

Small is not a limitation. Small is how you learn what production actually means before you've spent three months building something that doesn't work.

Where to start

• This week, define what "production" means for your use case. Write down three things that would break your business if they went wrong: data loss, errors that slip through, or downtime. That's where your production work starts. Share this list with the person who will actually use the tool.

• Pick one concrete workflow to automate, not a whole department. A single type of task, for a single person, over one month. Define what success looks like: how much time do they save, what data do they keep, what errors are unacceptable.

• Ask who owns the result. If you're working with a vendor, ask in writing: where does the data live, who owns the code, what happens if you want to leave. Get a straight answer. If you don't like the answer, that's information you need now, not after you've built something.