Build
Custom software development for the thing nobody built yet
The six roads on this page cover what companies ask for most often, and they do not cover everything. Plenty of work is specific to one company, one industry or one regulator, and that is the work nobody sells you a product for.
You describe the work · the agent writes the code · your team reviews before anything goes live
In short
Custom software development normally means a specification, a supplier and a wait measured in quarters. AI app development changes the first part: you describe the thing you need in your own words, the agent asks the questions a good analyst would ask, writes a plan you can correct, then writes the code, runs the tests and hands it over for approval. Whether the result looks like a register, a calculator, a portal or something with no obvious name matters less than whether it fits the work.
Things departments describe in their own words
- A register for samples, permits or inspections with its own numbering
- A calculator that applies your pricing rules instead of a fragile spreadsheet
- A portal where suppliers or partners submit what you keep chasing
- A reporting pack assembled from the files three systems produce
- A scheduling board for shared equipment, rooms or vehicles
- A register that satisfies the auditor who visits your industry
A process from Finance
The problem
Supplier contracts renew automatically, the notice periods live in a shared mailbox, and twice a year one renews that nobody wanted.
What the agent builds
The agent builds a register where each contract carries its value, its notice period and its owner, and where the owner is reminded before the window closes. Anything approaching a deadline without a decision rises to the top of the list.
What you end up with
One place that answers what renews next quarter, who decides and what it costs. No product on the market was shaped like that, so it was described instead.
The list of roads is not closed
Six named roads exist because they are the common answers, not because they are the only ones. The selector on the home page ends with this option for a reason.
- Your industry has a document, a register or an approval nobody outside it has heard of.
- Your company merged twice and the process between the halves lives in a person, not a system.
- A regulator asks for something in a shape no product produces.
- The thing you need is small, strange and worth an afternoon a week to the team that needs it.
You do not have to classify it. Write what happens today, who suffers and what a good day would look like, and the agent will work out whether it is closest to a web app, a connection or something with no name at all.
How an odd request becomes a plan
The unusual part of a request is rarely the technology. It is the rule that only your company applies, and it takes questions rather than guesses.
- What exactly is the record: a case, a batch, a claim, a booking.
- Who creates it, who changes it and who is allowed to close it.
- Which rule has an exception, and who is allowed to make the exception.
- What has to be provable afterwards, and to whom.
The answers become a plan in ordinary language before any code exists, and you correct the plan in the same conversation. That correction is the cheapest moment in the whole process. Once the plan is right, the agent writes the code, runs the tests and hands the result over for a person to approve, exactly as on every other road. The full loop is on how it works.
What you hear if it is a bad fit
Some requests should not be built, and hearing that early is worth more than a polite attempt.
- A product already does the job properly, and the honest answer is to buy it.
- The process itself is the problem, and software would only make the mess faster.
- The rule cannot be written down yet, because two departments disagree about it.
- The scope is a programme rather than an app, and it needs cutting into pieces first.
In those cases the agent says so in the plan, and usually proposes a smaller first piece that settles the argument. Nothing is built without a person approving it, so a bad fit costs a conversation. When the shape is clear, the smaller piece often turns out to be all that was needed, and what it costs is on pricing.
Questions teams ask
We cannot describe it precisely. Is that a problem?
No, that is the normal starting point. Describe the day you have now: what arrives, who touches it, where it stalls, what gets asked at the end of the month. The agent turns that into questions, and the questions turn into a plan you can correct before a single line of code exists.
Is there a limit to how strange the request can be?
The practical limit is whether the work can be described. A rule that depends on judgement nobody can put into words is hard to build anywhere. Everything else, including the registers and calculations peculiar to your industry, is ordinary code once the rules are written down.
How does this compare with hiring an agency?
The main differences are who holds the knowledge and how a change is made. Here the code sits in your repository from the first day, and a change is a conversation rather than a quote. You also see the plan before the work starts, which is where most misunderstandings with an external supplier begin.
Can we start small and grow it later?
That is the usual pattern. The first version covers the part that hurts most, your team uses it, and the gaps become obvious within a fortnight. Each addition is described in the same conversation, and because the tests came with the first version, later changes do not quietly break earlier work.
More the agent builds
Describe your own thing
Write what happens today and where it hurts. The agent works out the rest.