Can we start smaller and expand later?

Yes, and usually you should. We would rather deliver a narrow system that is genuinely used than a broad one that is half-adopted. The design work should anticipate the second phase; the build should not pay for it before you know it is needed.

What if we want to take it in-house later?

That is a normal and healthy outcome, and the handover is written into the contract. The code is already yours, the infrastructure is already declarative, and the runbook is written for someone who was not on the project.

Custom web applications

The system your business actually runs on, built properly

Most businesses reach a point where the spreadsheet, the shared inbox and the three subscriptions holding the process together stop being funny. The work has a shape no product models, the people doing it have invented workarounds nobody wrote down, and every quarter the workarounds cost more. A custom application is the right answer to that problem and the wrong answer to almost every other one, which is why the first thing we do is try to talk you out of it. When it survives that conversation, what you need is software that will still be maintainable when the person who commissioned it has moved on.

What the work involves

Discovery that ends in a written scope and a fixed price, not a rolling estimate
A typed contract between front end and back end, so a field renamed on one side breaks the build rather than production
Authentication, authorisation and audit designed at the start — retrofitting permissions is the most expensive rework there is
Database schema designed for the queries you will actually run, with migrations under version control
Monitoring, structured logging and alerting wired up before launch
Automated tests on the paths where being wrong costs money
Deployment as code, so the environment can be rebuilt rather than remembered

Why we are credible at this

KamoCRM is itself a large custom web application: around forty backend services and roughly a million lines of Java behind a TypeScript front end, deployed to a cluster we operate. We are not describing a methodology we read about.

What moves the price

We quote after discovery and the number is fixed before anything starts. These are the things that move it, so you can see roughly where your project sits before you talk to us.

How many distinct user roles the system has, because permissions multiply scope faster than screens do
Whether data must be migrated from an existing system, and how clean that data actually is
Integrations with systems we do not control, especially any without a documented API
Compliance obligations — regulated data changes the design, not just the paperwork
Whether you need us to operate it afterwards or hand it to your own team

Proof we have done this

The cluster we run our own company onA production Kubernetes platform, operated by the people who deploy to it A distributed data layer, chosen deliberatelyDistributed SQL, wide-column, cache, object storage and vectors — each for a reason Documents, signatures and the paperwork layerCollaborative editing, e-signature and OCR, built rather than bought

Questions we get asked

Other App Development work

API and integration developmentMaking two systems agree, including the one with no documentation Mobile applicationsCross-platform where it makes sense, native where it does not AI and retrieval systemsAssistants that read your documents, and know what they are not allowed to read Real-time systemsLive data, messaging, presence and media — the unforgiving end of the web

All App Development

Tell us what you are trying to do

A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.

Start a conversation I already use KamoCRM How we quote