Most software is built to launch.
We build it to run.
Custom platforms, products, and AI systems, built by a senior team that stays on after launch.
Talk to us- 8tenants on one platform
- 3public products
- 60,000+users on it
- 6 yearsin continuous production
That platform is Wibo. We built it, and we still run it.
It is built and changed through AI flows end to end, and the architecture was set up for that before the first tenant arrived, so adding a tenant or shipping a change does not need more than one engineer running it.
Our team has fourteen years of production engineering behind it, at IBM, Vodafone, M-Files, Bitwise, Piceasoft, Thinkful, Piano, and more.
What we build
AI systems
AI built into how your company works, inside your systems and your processes, rather than a chatbot bolted to the side.
- AI does the work your team does by hand today, iterating and checking itself against acceptance criteria before anyone sees the result
- Agents with real access to your systems, with a person approving the decisions that matter
- Retrieval over your own documents and data, with memory that persists between conversations
- Evaluation harnesses, so quality is something you can check
- AI inside your own delivery, from the software lifecycle to the administrative work around it
- Deterministic automation underneath, so the parts that have to come out the same every time do
Products
One application, built end to end and built to be handed to a team that will keep growing it.
- The API and the data model underneath
- Web, and iOS and Android where the work happens away from a desk
- A design system, so the surfaces stay consistent as more people touch them
- Offline behaviour and sync where the phone cannot assume signal
- Rebuilds and migrations off a system that has stopped paying for itself
Platforms
One system serving many separate organisations: branches, franchises, member bodies, regional offices.
- Separate data and separate users per tenant, one codebase to maintain
- Several stakeholder types in the same system, each seeing only their part
- Per-tenant configuration and branding without forking the code
- A new organisation onboarded as a configuration change rather than a project
- Migration off the per-client installations you are maintaining one at a time
Audit, Build, Run
Technical Audit
Typically two to four weeks.
First we go and measure what is actually there: what your data looks like, what the systems you need to talk to actually return, where the current one slows down, and what it still makes people do by hand.
Then we recommend what to do about it, and the measurements are the argument. Sometimes that means building less than you planned, or something other than software, and we say so.
Then we test the assumption our recommendation rests on, with real code against your real data, before anyone commits to a build.
If you arrive with a defined system, most of that lands on the plan you already have: whether it survives your real data, what it will actually cost, and what it has not accounted for. If you arrive knowing only that something is wrong, more of the time goes into finding out what.
You end up with a Build Plan: the architecture and approach, the risks written down, the work sequenced, and the first phase priced. It is yours to keep, including if you take it to somebody else to build. You leave with your questions answered and the evidence behind them instead of a proposal meeting in the calendar.
- Typical timeline
- 2 to 4 weeks
- Output
- Build Plan, plus a feasibility test on your data
- Best for
- A build you are about to commit to, a codebase you have inherited, or a company that knows something should change and not yet what
- Terms
- Yours, including if you build it elsewhere
The assumption we test is agreed with you in week one. It is one assumption, not a working version of the system, and it is the one that decides the outcome even when an easier one is available. A demo is built to show you it works; this is built to find out whether it does. Either the assumption holds and the plan stands, or it does not and the approach changes in week two rather than month eight. It is a test, not production code and not a slice of the product. Sometimes it becomes the foundation of the build and sometimes we throw it away, and both are fine at this stage.
Build
The first phase is quoted inside the Build Plan, so the number comes out of work already done. That is why it can be a fixed price, and why the audit comes first. Where scope genuinely cannot be fixed, we bill for the time instead, and you know which of the two you are getting before you sign anything.
Run
We run what we build: architecture, infrastructure, monitoring, on-call, and continued development. Monthly after a build, or on its own for a system somebody else built, once an audit confirms it is supportable.
If the system is down or your users cannot work, we answer at any hour.
How to start
Audit, then build. Recommended.
2 to 4 weeks, then the build
Build directly, when the scope is already defined.
Straight to delivery
Ongoing technical ownership. Architecture, delivery, infrastructure and on-call.
Continuous
Engineering under an administrative owner. Somebody else holds the mandate and the client relationship, we do the build.
Per project
Embedded team. A team with a named lead, working to your product owner and your schedule.
Long engagement
Our smallest builds run a few months. Below that we would either put one of our engineers alongside your team, or point you at a cheaper way to get it done. We will say which on the first call.
The foundation
Every system is different.
The ground under it is not.
Every build sits on the same four layers, and we own all four. Application, the surfaces people use. Orchestration, the agent, the automation underneath it, memory and a knowledge layer over your own information. Infrastructure, defined as code, isolated per client, monitored, with someone on call. Delivery, the harness that produces the other three: from the first call to a running system, with AI in the loop and one review standard applied to everything, regardless of who or what wrote it.
That is why a new system starts from something that already runs instead of from an empty repository. AI writes a great deal of it, under the same review standard as everything else, and between those two things you get the system sooner and for less than the quote you are comparing us to.
These four layers are what run the platform at the top of this page: eight tenants, three public products, more than sixty thousand users, six years of continuous production with one engineer operating it. That is a design decision, not a shortcut.
Wibo
Platform · Multi-tenant · Public products
One codebase, eight tenants, each with its own data.
- Students, schools, employers and regional career centres
- Separate public products running off it, each with its own front end and its own users
- We are moving it to a new version right now, underneath everyone using it
More than 60,000 users.
Wibo is ours. Not a client, not a showcase. We part-own it, and we do all of its technical delivery, which is why we can show you the inside of it.
Career guidance is dozens of separate efforts that are not built on each other, while a kid still picks a school on what a parent thinks and what a friend said. Wibo is the layer underneath: one system that the schools, the regional centres and the products built for them all run on, instead of each starting from nothing. The result is a choice made on something real, first by the kid and later by the adult they become.
[Screenshot: one live public product running on Wibo. Unretouched, honest crop, 1216 × 720, radius-none, rule hairline, no browser chrome. Supplied at build.]
Questions we get
How long have you been doing this?
We have fourteen years of production engineering behind us, at IBM, Vodafone, M-Files, Bitwise, Piceasoft, Thinkful and Piano, to name a few. The engineers delivering today have worked together for about ten of those years, and the platform above has been in production for six.
Who actually writes the code?
The people you meet. We have worked together for about a decade, and we are all in the code. When a project needs more people, we bring in engineers we have already delivered with. You will know who is on your project before you sign.
Is Wibo a real client, or a showcase?
Neither. It is a platform we built, part-own, and still run. A showcase is built to be looked at. This has people on it who would notice if it stopped.
Does our code go into a model?
No. We do not train on your code or your data, and we do not use a provider in a configuration that does. Which provider we use is chosen per project, and it can stay inside the EU where that is a requirement.
Who owns the IP?
You own what we build for you, from the first commit: the application, the data model, the repositories and the infrastructure accounts. What stays ours is the tooling we arrived with, the libraries and the deployment machinery, licensed to you as part of the system. On a build, that means you own essentially everything you paid for.
How do you price?
The number depends entirely on what you are building, so a published range would be no use to you. What we do instead is get a real one in front of you early: the first phase is priced inside the Build Plan at the end of the audit. Fixed fee where the scope can honestly be fixed, time and materials where it cannot, and we say which before you sign.
What if something breaks at three in the morning?
With Run, somebody answers. The agreement defines critical as the system being down or your users being unable to work, and that is what we commit to at any hour. A bug or a small change waits for business hours. We write the definition down because otherwise every problem is critical by somebody's account, and a service with no edges is one nobody can staff.
"AI-native" usually means nobody read the code. Does it here?
AI writes a lot of what we ship: scaffolding, tests, migrations, first drafts of most things with a clear specification. What it does not do is decide. Nothing reaches your product unreviewed, and nothing ships that one of us cannot explain. The platform above is the evidence, because it is built this way end to end, and we are moving it to a new version right now with zero downtime as a hard requirement, while more than sixty thousand people rely on it. Anyone can say AI wrote their code. Running that migration under that constraint is where you find out whether anybody was reading.
Tell us what you are building.
The first call is about your problem, not a pitch. If we are the right people for it you will know quickly, and if we are not, we will try to point you somewhere better.
The other half of Serein
Running a business rather than building software? The other half of Serein is a private AI assistant for individuals and small to mid-size companies. It knows how your business works, it connects to your systems, and the repetitive work runs underneath it.