Questions people ask before they commit

Please do — that's the conversation we'd recommend having. Describe the problem you're facing and we'll help work out whether an app is really the answer, and the simplest version that would solve it.

No. A rough description is enough to start. Bring the messy version if you have one — screenshots, spreadsheets, the workaround your team invented. That usually tells us more than a polished brief.

We ask what breaks today, who it breaks for and how often, then separate what genuinely has to be built now from what can wait. You leave with a shared understanding of the problem and a first read on whether a ready-made app fits or it needs building from scratch. It's free and there's no obligation attached.

We'll say so, and say why. Taking on work we're not the right studio for helps nobody — you'd feel it three months in, and so would we.

Cost varies with the scope of work agreed. We don't publish flat pricing because no two projects are alike. After the consultation you'll receive a written proposal, including the assumptions behind the number, before any commitment.

It depends on complexity. Small, well-defined work can be done in days, while a large system can run for months. We give you a firm estimate once we understand the scope.

That's usually what we recommend. Build the part that earns its keep first, get it into real use, then let what you learn decide the order of everything else. It also keeps the first invoice smaller.

It gets discussed before it gets built. A change is quoted as its own piece of work with its own effect on the timeline, and you decide whether it goes in now, later or not at all. Nothing is added quietly and settled on the invoice.

Ready-made starts from an application we've already built and adapts it to your brand and needs — faster and lighter on budget. Custom is built from scratch around your specific workflow, which gives you more freedom but takes longer.

Web applications that run in a browser, mobile apps for Android and iOS, or a combination. We help you decide based on who will actually be using it.

Yes. We design the screens before writing code, then build in stages — and each stage lands somewhere you can log in and use it, not just a screenshot in a status update. Feedback goes in as we build rather than piling up for the end.

Yes. Taking over and repairing existing applications is routine work for us. We review the current state first, then tell you honestly what we'd recommend doing.

Yes. Maintenance, fixes and further development can continue on agreed terms. We define what support covers up front so there's no ambiguity later.

You do. Once the work is completed and handed over, the code and the data belong entirely to you.

You can. Source code, hosting and service accounts are transferred into your name at handover, and the documentation is written for someone who wasn't in the room. We'd rather you stay because the work is good than because leaving is difficult.

We can set them up and manage them for you, but they're registered in your name from the start. If you'd rather run them yourself, we'll hand over the setup and the instructions.