We do not sell AI-assisted engineering off a slide deck. For a year we turned our own company into a laboratory and built thirteen systems with this method. Nine of them run in production today and cost us real money whenever they misbehave.
This page is what we could not find when we started: a decision framework with numbers in it. Not a ranking of companies.
Ask five suppliers whether they are an "AI software house" and five will say yes. They will be talking about two completely different things, and which one they mean decides what you get for your money.
AI assistants are a tool in an engineer's hands, the way a compiler and a debugger were before them. Code is produced faster, so the project costs less and arrives earlier. But the system you receive has no artificial intelligence inside it. It is ordinary, solid software, built for less.
A language model, search across your own documents, an agent that performs tasks, machine learning that predicts failures. Here the AI is in the product: your company starts using it, not just the contractor while writing code.
A supplier who only has the method is selling you speed. You get the system sooner, but your company still does not use AI.
A supplier who only has the feature is usually one of two cases.
Either a classic software house that added AI to the offer, and then two questions are worth asking. First: if they do not use AI in their own build process, on what basis will they build good AI features into your product? Second: even if they do build them, those features will arrive at the price and pace of a classic software house, which means expensive and slow.
Or an agency working on a ready-made platform, in which case the solution works for as long as you fit inside what the platform anticipated, and for as long as the platform exists.
A supplier who has both builds quickly and leaves you a system that genuinely works with AI. That is where we stand.
What the four kinds of AI software are, and what each of them costs, is set out separately in AI software: four different things sold under one name.
The market looks uniform only from the outside. Inside it is five different business models, with the risk distributed differently in each.
| Supplier type | AI in the method | AI in the product | Whose code | Time to MVP | Range | Who maintains it | Where it fails |
|---|---|---|---|---|---|---|---|
| Classic software house | ✗ | ✗ | yours, under contract | months | 50k – 2M USD | a team of 5–15 | small budget, shifting scope |
| AI software house | ✓ | ✓ or ✗ | yours, under contract | days or weeks | 1.5k – 75k USD | a small team | large legacy, safety-critical systems |
| AI / automation agency | ✗ | ✓ | lives on someone else's platform | days or weeks | billed per operation | the supplier | when you need your own logic |
| Staff augmentation | - | - | yours | - | billed by the hour | you | when you have nobody to manage them |
| Off-the-shelf SaaS | ✗ | ✓ or ✗ | you do not have it at all | days | per-user subscription | the supplier | when the process is your advantage |
An important caveat before the table. The ranges below come from figures published by development vendors in 2026, not from an independent market study. Read them as an order of magnitude rather than a price list. What is consistent across sources is the shape, not the precision.
| What | How much | Source |
|---|---|---|
| MVP, simple | 8k – 20k USD | [1] |
| MVP, medium | 20k – 45k USD | [1] |
| MVP, complex or AI-native | 45k – 100k+ USD | [1] |
| Mid-market solution | 150k – 500k USD | [2] |
| Enterprise system | 500k – 2M USD | [2] |
| Annual maintenance | 20–30% of project value | [2] |
| Data preparation | 40–60% of project timeline | [1] |
| AI software house, first working system | 1.5k – 7.5k USD | our own figure ↓ |
| AI software house, operating system for a mid-sized company | 15k – 75k USD | our own figure ↓ |
They are ours, not the market's, and they hold in one scope: new systems built from scratch, which is the only class where the speed-up behind them is documented. They are converted from the currency we work in, so read them as a band rather than a quote. The method behind them, together with the studies that contradict it, is described in What is AI-assisted engineering.
The market rule of thumb is 20 to 30 percent of the project value per year. Here is our own infrastructure bill instead, per system, per month:
| System | Cost per month |
|---|---|
| Monitoring portal | ~1 USD |
| Invoicing automation | ~0.42 USD |
| Mailboxes, three accounts | ~1 USD |
| Notification hub | 0.10 USD |
| Demand radar | 0.05–0.20 USD |
| Content production board | close to zero, shares existing resources |
| AI models, usage-based | from cents per report to tens of USD |
All our internal systems together cost tens of dollars a month.
Why "tens" when the table adds up to a few. Because the infrastructure really is a few dollars, but the AI models are billed separately and by usage. A single model-written report costs cents. One implementation error is enough to make that bill grow: it happened to us once and consumed 70 USD in two weeks before our monitoring caught it. Our alert thresholds were set too high. That is why we round the number up.
The number does say something useful about architecture, though. A system designed to pay for consumption rather than for reserved capacity generates no cost while nobody is using it. A supplier quoting several thousand a month for maintenance should be able to say exactly what for.
The market does not agree on this, and it is better to show the disagreement than to pretend it away. One side lowers prices, arguing that model costs have fallen by a factor of ten to a hundred in two years, so producing software got cheaper too. The other side warns about exactly that arithmetic: the red flags are "an app from 5k", "an MVP in 4 weeks", "a fixed price of 100k with no defined scope" [3].
Our position: a low price without a defined scope is not an advantage. It is a transfer of risk from the supplier to you, and you pay it later, in changes.
We claim a fivefold speed-up ourselves. Below are the results of research into how AI assistants affect the pace of work, including the ones that do not favour that claim.
| Strong speed-up | No help, or harm |
|---|---|
| boilerplate and application scaffolding | work on large, mature legacy |
| standard data operations, API interfaces | debugging |
| systems built from scratch | complex domain logic |
| entering an unfamiliar technology | reviewing somebody else's code |
Five times faster, for new systems built from scratch. Not on somebody else's legacy. Not on debugging. Not as a universal multiplier.
Our implementations sit exactly in that class, which is why the number works for us:
It is worth asking any supplier where their multiplier stops applying. The absence of an answer to that question is itself information.
Two jurisdictions, one direction. In the European Union, a work requires a human author, so purely generative output is not protected by copyright and is not a "work" in the legal sense. In the United States the Copyright Office reached a comparable conclusion in the second part of its report on copyright and artificial intelligence, published in January 2025: material generated without meaningful human contribution is not registrable [10].
Code with a meaningful human contribution behaves normally: the specification, the architectural decisions and the review are human authorship, and the result is protected on ordinary terms.
The practical consequence is not the one most buyers expect. The risk is not that somebody else owns your code. The risk is that nobody does, which means nobody is stopped from using the same fragment elsewhere. That is why the contract question worth asking is not only "will the rights be transferred to me", but also "how does this code come into being".
| A good answer sounds like | An evasion sounds like |
|---|---|
| "Every module has a specification and a named reviewer, and that is recorded." | "Everything is generated by AI, so it is fast." |
| "The repository is yours from day one, we work in it." | "We will hand over the code at the end of the project." |
| "Here is the commit history and the review record." | "We do not share internal process details." |
The above is not legal advice. It reflects the state as of September 2026.
Briefly, because in most cases the answer is simpler than it looks. The Act reaches any supplier placing an AI system on the EU market, so it matters whether or not your own company sits inside the Union.
Your typical case. A bespoke transport system, an invoice workflow, a production panel: these are not high-risk systems. Your obligations come down to transparency and staff competence. High risk begins where AI assesses people: recruitment, scoring, access to benefits. And that starts in December 2027.
The above is not legal advice. The dates have moved before, so check them before relying on them.
| # | Question | A good answer | A bad answer |
|---|---|---|---|
| 1 | What exactly does the AI model do here, and what is an ordinary condition? | names the decision and its boundary | "the whole thing is AI-powered" |
| 2 | Do you use AI in your own build process, or only in what you deliver? | describes both, separately | treats them as the same thing |
| 3 | Who reviews the code before it reaches production? | a named person and a named moment | "AI checks it" |
| 4 | Where did this method not help you? | lists areas without pausing | hears the question for the first time |
| 5 | Show me a system you built for yourselves and use daily. | shows it, with the bill | shows a client portfolio instead |
| 6 | Where does my data land, and does it train anyone's model? | points to the contract clause | "we use AI" with no detail |
| 7 | What does maintenance cost, and what exactly is in it? | splits infrastructure from human time | a single monthly figure with no breakdown |
| 8 | What happens to my system if you disappear? | repository and documentation are yours already | "that will not happen" |
| 9 | What is the scope of your speed-up claim? | names where it stops applying | presents it as universal |
| 10 | What tests stand behind this, and how many are there? | gives numbers | "we test everything manually" |
Nine situations where it is worth looking for a different supplier, including instead of us.
A free audit ends with a diagnosis rather than a quote pushed at you. If you fall into one of those nine situations, we will say so and point you at who to look for.
This returns to the distinction from the beginning. Below is the second half: AI as a product feature. Every example is one of our own systems.
The model reads the state of every system and on Monday morning sends the owner a report with recommendations. Design decision: a deterministic algorithm computes the priority, the model only puts the result into language. The same situation always produces the same priority, so the model does not decide what is urgent.
It also extracts facts from correspondence and suggests them to the customer database. The first learning cycle collected ten corrections out of 838 messages.
The system recognises the signal, drafts a reply and puts it through a quality gate. A human always sends.
A weekly market review with the company context embedded and a validator that rejects any signal without evidence, meaning a specific address and quote. Without it, research produces plausible-sounding generalities.
In its answers the system separates fact, calculation, missing data and conflicting data. It never presents a guess as a certainty.
That is the answer to the most common worry about AI in a company: that something will act without anyone knowing. It can be designed the other way round.
That day the founder left the company he had co-built for years. The market was loud about a coming breakthrough in how software is made, and it had to be tested in practice. A test like that cannot be run in evenings; it needed all the available time.
For a year RapidLogic stopped being an agency and became a laboratory, with one task: run as many tests as needed to get a grip on the incoming technology before it becomes the standard.
Between 11 July and 26 August 2026, so in 46 days, thirteen systems were built. Nine run in production today and operate the company: a portal monitoring the state of every system, handling for three mailboxes, an invoicing automation, a customer database, a demand radar and a content production board.
Because the usual mental model of that sentence is thirteen products for sale. These are internal systems for a company of one, each solving one clearly defined problem, without a user interface for external clients, without onboarding, without a support department. That is a different class of work from a commercial product, and the number should be read with that in mind.
Rigour can be shown in numbers the same way pace can: automated tests on the key systems stand at 103/103, 114, 44, 25/25 and 18/18. The roadmap holds 129 items, so the technical debt is counted rather than hidden. A full code review at the end of July produced 13 findings; both high-severity ones were fixed and deployed.
Four areas with the shortest path from implementation to effect:
What is not on that list: medical diagnostics and regulated financial services. Different league of requirements, different teams, not our field.
By two things worth separating: the build method (AI assistants as an engineer's tool, so faster and cheaper) and the product feature (AI built into the system your company uses). Some suppliers have only one of the two. Ask which.
Code with a meaningful human contribution, yes, on ordinary copyright terms. Purely generative output is not protected in the EU and is not registrable in the US. So ask not only about the transfer of rights, but about how the code comes into being.
For new systems built from scratch, yes, and that is the scope in which we state it. As a universal multiplier, no. The METR study found experienced developers working on mature code were 19% slower with AI, and 45% of developers say debugging AI code takes longer.
The market rule of thumb is 20 to 30 percent of the project value per year. Cloud infrastructure alone can be far cheaper: our systems cost tens of dollars a month. But maintenance is also somebody's time. Count both before comparing offers.
Safety-critical systems, certification requirements, a need for a large team over many months, pure maintenance projects on large legacy, processes with no competitive advantage in them, and when you have no decision-maker on your side.
Ask them to show a system they built for themselves and use every day. Ask what the model does here and what is an ordinary rule. Ask where AI did not help them.
Which is why the code belongs in your repository from day one, the documentation has to allow another team to take over, and the system should not live solely on the supplier's account. Ask about it before signing, not after.
It does not have to. Model providers offer a no-retention mode, and where confidentiality demands it, a locally hosted model is possible. A good answer is specific and points at the data processing agreement. "We use AI", with no indication of where the data goes, is a bad answer.
Because a price without a scope is not a price. The higher figure often includes a team, tests and maintenance; the lower one is sometimes an entry price after which you pay for every change. Compare the answers to the ten questions above, not the figures.
A free digital audit takes one to two days. It ends with a written diagnosis: what in your company can be built quickly, what is not worth touching, and what a realistic order of magnitude looks like. If it turns out that a subscription is enough for you, you will hear that too.
Last updated: 3 September 2026