How is this different from sponsoring a feature through the request system?

Scope and ownership. A sponsored feature request changes KamoCRM itself: it ships to every tenant, we maintain it forever, and it costs less because everyone shares the benefit. Application development builds software for you: you own the code, it does what only you need, and nobody else gets it. If your requirement would improve the product for everyone, we will point you at the request system, because it is cheaper for you.

Do you work in languages other than Java and TypeScript?

Those two carry most of our own platform, along with Rust for the systems that need it, Python for the machine-learning work, Go for the network services and Kotlin for Android. We will not pretend fluency in a stack we do not run. If your project needs something outside that range, we will say so rather than learn on your budget.

Can you take over an existing codebase?

Often, but not always, and we will not decide from a description. Takeover starts with a paid audit that reads the code and the infrastructure and reports honestly on what it would cost to work in. Sometimes that report says the sensible thing is to keep the existing team. You get the report either way.

You do, from the first commit, in your repository. We do not hold the source, we do not license it back to you, and nothing we write for you becomes a product we sell to someone else without your agreement. The exit path is documented in the contract.

We quote after discovery, and the number is fixed before anything starts. We publish what moves it rather than a table that would be wrong for your project. There is no minimum engagement, but the work we are good at is rarely small.

We Build Software. It Is Not a Side Business.

The same engineers who wrote KamoCRM's forty backend services, run its Kubernetes cluster and keep its mail, phone and video working will build yours. Ask for the architecture diagram in the first call — there is one.

Most firms selling application development have never operated what they shipped. They deliver a repository, invoice, and leave. The first production incident is the client's problem, and it arrives about six weeks later when a certificate expires or a queue backs up. Operating your own software for years changes how you write it, and there is no shortcut to learning that.

We run a production Kubernetes cluster carrying our own platform: a hundred-odd deployments, our own mail servers, our own telephone switches, our own WebRTC media servers, our own inference and vector search. Every one of those is something most development shops would call an integration and hand to a vendor. We built and operate them, which is why we can tell you in the first conversation which parts of your idea are hard and which parts only look hard.

That also means we will talk you out of things. A large share of what gets sold as custom software is a configuration problem wearing a budget. If your requirement is met by something that already exists, the honest answer is worth more to you than the invoice, and we would rather have the next project than this one.

What usually happens, and what we do instead.
The usual arrangement	How we work
Hands over a repository and a final invoice	Operates what we ship, or hands it over with the runbook that operates it
Calls every third-party service an integration	Has written the mail, telephony, video and inference layers ourselves
Estimates in story points that drift	Quotes a fixed number after discovery, and tells you what would change it
Staffs your project with whoever is on the bench	Is a small team that ships to production weekly; you meet everyone
Owns the hosting so you cannot leave	Writes the exit into the contract and documents the migration

What you actually get

A written scope and a fixed price before any money moves
Source code in your repository from the first commit, under your licence
Infrastructure as code — the cluster manifests, not a screenshot of a console
Monitoring, alerting and log aggregation wired up before launch, not after the first outage
A runbook written for whoever operates it next, including us leaving
Load and failure testing against the numbers you actually expect