Prototype as spec
It shows what’s needed in more detail than any requirements document. We read it, we don’t start over.
01Your prototype works. Can you run it?
A prototype proves that something can work. It doesn’t prove that you can rely on it. We take working ideas into production with the architecture, security, testing and operations that real software needs.
The prototype isn’t the problem
In nearly every company there’s now a prototype. Built fast, often AI-generated. It works, and that’s exactly what makes it difficult.
It answers whether something is possible and leaves the other untouched: can you run it, with real users and real consequences. The prototype isn’t the mistake.
Why no client names2x10
Our clients hire us to build what gives them an edge. Confidentiality is part of the job. Publishing the details could give that edge away. We’ve delivered in regulated environments and on projects worth hundreds of millions.
What we've built
A rebuild for a client, from a prototype that already worked and was presented to customers. Like almost every fast-built prototype, it carried real security gaps.
The rebuild enforces every architectural rule as a build failure: what isn’t allowed can no longer be written. Golden-file tests prove the numbers didn’t change, and no merge skips the gate.
Our own development runs through AI workflows, with checks that run on every file an agent touches: formatting, documentation, architectural boundaries.
That’s why we know where AI-generated code breaks. It produces plausible code quickly, and plausible isn’t the same as correct. We rely on it daily, which is why we built the guardrails.
Prototype to production
What actually happens in the transition
Selective rebuild
Correct behavior stays, checked against the prototype. Everything around it is rebuilt: access control, traceability, operations.
02Clean handover
Not dependent on whoever built the prototype. Documented, tested, handed over. That’s the actual deliverable.
03Production questions2x10
What makes them hold up
The rebuild has to earn its cost. Three questions show whether it did.
- Can the rebuild prove nothing changed?Otherwise you own a new system and an old argument, and the argument usually wins.
- Where do the rules live?Rules in documents erode. Rules that break the build stay, because they are the shortest path back to work.
- Why not just secure the prototype?That defers the bill, it doesn’t settle it, and the interest is paid by whoever is on call.
What we could build for you
- We assess an existing prototype and tell you honestly what it carries and what it doesn’t.
- We turn it into a system that withstands operation, access control and audits.
- We prove the results stay the same wherever they were already right.
- We hand it over so your own team can keep building.
- And whatever you have in mind that AI and solid software engineering could make possible.
Under the hood
Architecture · domain-driven design · enforced architectural boundaries · row-level security · Verification · golden-file tests · multi-stage CI gates · no manual overrides · Delivery · infrastructure as code · migration strategies · handover documentation
Most engagements start small: talking it through, a few weeks of engineering, something real you can judge. If it works, we take it further.If it doesn’t, you find out early
More work2x10
AI Governance
You stay in charge
View themeNovid20 · Our own product
Millions of users
View themeAI Agents
Beyond the demo
View themeN° 06 Contact
Tell me what you’re planning
No form, no ticket system. Email me directly and you get me, not an inbox someone else manages.
Moritz Miedler · Founder, replies personally2x10 Technologies · Viennahello@2x10.com