When the off-the-shelf answer covers 80%, we write the other 20%
Sooner or later every business hits the point where standard software says no. Most vendors then offer two options: bend your process to fit the tool, or pay to wait years in someone’s development queue. We are programmers, not resellers — the platform we build on is our own code, so a missing integration, an unusual device or your specific business logic is not a ticket in somebody else’s backlog. Start with the small piece that solves the most painful part, and grow it once that has paid for itself.
Four ways the missing piece usually gets built
Development on top of a finished platform
You are not starting from zero. Access, devices, users, payments, reporting and notifications already exist and already work — we add the part your business needs on top. That means a fraction of the scope of bespoke software written from scratch, and a working result in weeks rather than quarters.
Integrations and APIs with your existing software
REST, GraphQL, webhooks, MCP and white label — data moves into your accounting, payroll, ERP or CRM without manual exports. If the integration you need does not exist, we write it: that is routine work here rather than an exception, and you stop having to keep a person stationed between two systems.
New devices and protocols
When you have equipment the platform does not yet know — an old controller, an industrial sensor, an unusual lock or a meter — we add support for it. On the IoT side that covers both choosing and installing the hardware and writing the driver that makes the device speak the same language as everything else.
Maintenance and evolution, not a one-off project
Finished code does not get filed away: we keep it running, update it alongside the platform and extend it when the business changes. That avoids the usual outcome where a bespoke piece becomes, within a year, the obstacle everything else has to work around.
A small piece of code that removed a full-time job of clicking
Picture a company where everything but one thing already worked. Access, devices and reporting lived on the platform, but prices and stock lived in an old system that could not be replaced — so every change was made twice, once in each place. Somebody spent an hour a day on it and got it wrong about once a week, which meant either the wrong price to a customer or goods that did not exist. The fix was not a new system but a single integration: read prices and stock from the old system, push them to the platform, send sales back. It took a couple of weeks rather than a quarter, because everything else was already there. After go-live, an hour a day of manual work and a weekly error both disappeared; a year later the same integration gained an automatic reorder suggestion when stock falls below a threshold. Neither piece was a large project on its own — together they replaced a person’s worth of daily clicking.
Related solutions
One app for everything
The platform custom work is built on — see what already exists before commissioning anything.
Smart Business
Six areas on one platform; custom work covers whatever is not there yet.
Vending and smart cabinets
A typical place where an unusual cabinet or terminal needs a little code of its own.
Custom solutions — answers
How big does a project have to be before you take it on?
Smaller than people usually assume. Because we are not starting from zero but adding to an existing platform, a typical first piece is a couple of weeks of work: one integration, one device driver, one report or one screen that removes a daily manual task. Those are the pieces most worth doing, because the effect is measurable immediately and the risk is small. Larger commissions are split into stages where each stage actually goes into use rather than waiting for the whole, so you see results before the budget is spent. And if the first conversation shows that your need is already covered by an existing feature, or that the development simply will not pay for itself, we say so — a quote that sells unnecessary code comes back to us later anyway.
Who owns the finished code and the data?
The data is yours unconditionally, and you can export it at any time in standard formats or through the API — we do not hold anyone by making departure technically hard. Code depends on what is being built: logic and integrations specific to your business normally fall under your licence, while generic platform improvements stay part of the platform and get updated along with it. That split is in your favour, because it means you are not later paying to maintain something that gets maintained for every client anyway. The exact terms go into the contract before work starts, not after, and they are written in plain language — if something is unclear, that is our failure, not yours.
How is it priced?
Smaller, clearly bounded pieces — one integration, one device driver, one report — are quoted at a fixed price, so you do not have to police development hours. Larger or vaguer work starts with a short analysis that ends in a staged plan with a price per stage; you then decide whether and how far to go. Ongoing maintenance and evolution normally run as a monthly fee tied to how much of the platform you use, rather than to how many hours somebody books. What we do not do is open-ended hourly work with no agreed outcome — it is the one model where the supplier’s interest and the client’s interest genuinely point in opposite directions.
Can you connect a very old or unusual system?
Usually yes, as long as it has some kind of output. In practice one of four things is enough: an API, database access, a file export, or a physical interface on the device. The hardest cases are closed systems with none of those, and there it is more honest to say there is no sensible route than to build something fragile that breaks at the next update. Before quoting we do a short technical review and tell you plainly which case yours is. On the IoT side the story is usually easier than with software: an old controller or meter can almost always be made readable, even if that means adding a separate reading module beside it.
Tell us about the one thing your software will not do
Describe the place where your process still needs manual work, or where two systems refuse to talk to each other — we will tell you honestly whether it is a couple of weeks of work, a larger project, or something not worth doing at all.