Services · The whole bench
From a botTo a system
If you can describe it, we can build it. React and Next.js on the front, Python or Node behind, Postgres underneath, shipped to somewhere you can afford to run.
- Next.js
- React
- FastAPI
- Node
- PostgreSQL
- Docker

The work that does not fit a category: an internal tool that replaces a spreadsheet nobody understands any more, a Telegram bot that quotes prices, a portal your clients log into, an API two systems talk through. We write it so the next developer can read it, and we leave you the repository, the deployment and the documentation.
What you get
- A working application, deployed, with the repository in your organisation
- A database schema that will survive the next two features
- CI that runs the tests and blocks a broken deploy
- A README a new developer can follow without calling us
How it goes
01 · Describe it in plain wordsNo spec document required. A conversation and a whiteboard are enough to start.
02 · Scope to a first versionWe cut it to what is useful in four to six weeks, and write down what got deferred.
03 · Build in the openYou get a staging URL from week one and watch it grow. No slideware, no status theatre.
04 · Ship and hand overCode, accounts, docs, a walkthrough. We stay on if you want us, not because you are stuck.
What changes
Something running
Not a prototype in a repository. A URL your team uses on Monday.
No lock-in
Every credential and every line is yours. Replacing us is a decision, not a project.
Readable handover
The next developer starts from documentation, not from archaeology.
Work from this bench
Straight answers
- How long does a first version take?
- Most are four to eight weeks. If something can be useful in two, we will say so and build that first.
- Can you take over an existing codebase?
- Often yes. We start with a short read-through and tell you honestly whether continuing or rewriting is cheaper.
- Who owns the code?
- You do, from the first commit. The repository lives in your organisation, not ours.
- Can you take over a codebase somebody else wrote?
- Yes, and it is a normal starting point. The first job is reading what is actually there rather than what the documentation claims, which is why the early weeks are discovery — inheriting a codebase blind is how a rewrite gets proposed for something that needed three fixes.
- Will you rewrite everything?
- Only if the honest answer is that a rewrite is cheaper than the repair, and that is rarer than it sounds. A rewrite discards working behaviour nobody wrote down, including the edge cases somebody fixed at two in the morning two years ago.
- What does the stack depend on?
- What the thing has to do and what your team can maintain after we leave. Next.js, Python, FastAPI, Node and PostgreSQL cover most of it, and picking something exotic that only we can operate would be optimising for the wrong party.
All services
Tell us the problem in plain words.Book the intro call






