Straight Answers About Getting Software Built

It covers a scoping conversation and a written document that comes out of it. We talk through what the software is supposed to do, who uses it and what already exists, then send back a proposed scope for a first release, a week-by-week timeline and a budget range with the assumptions it depends on. It is genuinely free and it is yours to keep — if you take that document to a different developer and get a better price, that is a fair outcome. What it is not is a binding quote: a firm fixed price follows once the scope is agreed in detail.

Design work on a new project usually starts within one to two weeks of the agreement being signed, and build work follows once the screens are approved. If your situation is urgent — a store rejection, a broken production system, a developer who has just walked out — say so on the first call, because triage work can often start much sooner than a full build. We will tell you honestly if we do not have capacity rather than accepting the work and then queuing it.

Less than most people expect. A description of the problem in plain language, a rough idea of who the users are, and any must-have integrations or compliance requirements you already know about are enough to get a range. Wireframes, a feature list or a competitor you want to point at all help narrow it. You do not need a specification document; producing one is part of what we do, and a spec written without an engineer in the room usually has to be rewritten anyway.

Yes. We will sign a mutual NDA before any detailed discussion of your idea, and there is a checkbox on the contact form to request one up front. Send us your own document if your lawyer has one you prefer, or ask us for ours. Either way you should assume the first email you send is not yet protected, so keep it general until the NDA is in place — a one-line description is always enough to get the conversation started.

Most first versions land somewhere between roughly $8,000 and $60,000. What moves the number is how many platforms you need, how many distinct screens there are, and whether the app requires the expensive pieces — payments, real-time features, an admin panel, offline support, or an integration with a system that was not designed to be integrated with. Our cost calculator gives you an indicative range in about a minute, and we confirm a real figure after a scoping call. A quote given before anyone understands the scope is a guess wearing a suit.

A fixed-price build includes scoping and technical planning, UI and UX design, the clickable prototype, all development work, testing across the devices and browsers we agreed to support, deployment and store submission, source code and handover documentation, and a defect-fix window after launch. The end-of-day written updates, the scheduled calls and the two-weekly demo builds are part of the engagement, not an extra line. Anything we plan to exclude is written in the proposal rather than discovered later.

Fixed price suits work where the scope can be pinned down before it starts — a first release, a defined feature set, a migration with a clear finish line. You get certainty on budget, and we absorb the risk of having estimated badly. A time-based or monthly dedicated-team arrangement suits work where the roadmap is genuinely going to change: ongoing product development, a long-running platform, or a research-heavy problem. Our usual advice is to take a fixed price for the first release and move to a monthly arrangement afterwards.

Fixed-price projects are billed against milestones rather than up front in full. A typical shape is a deposit to start, then payments tied to design sign-off and to specific build milestones, with the final instalment on delivery. Monthly engagements are invoiced monthly in advance. Milestones are written into the agreement before work begins so nobody is negotiating about money in the middle of a sprint, and intellectual property transfers to you when the final payment clears.

On a fixed-price engagement, work that is inside the agreed scope is our problem, not yours. If we estimated badly, we absorb it. What does change the price is scope you add later, and that is handled by a written change request: we describe the change, price it and state its effect on the timeline, and nothing starts until you approve it. That is the entire mechanism. Any agency that lets extra work accumulate silently and then presents a bill is running a different business to ours.

Third-party costs that we pass through rather than mark up: Apple and Google developer account fees, cloud hosting, domain and SSL, paid APIs and services such as SMS, mapping, email delivery or payment processing fees, premium fonts and stock media, and any commercial software licence your project requires. Ongoing maintenance after the defect-fix window is a separate retainer. We list the third-party costs we expect in the proposal with realistic figures so the total cost of ownership is visible before you commit.

You do. Full intellectual property in the software we build for you transfers to you on final payment, and the repository is in your organisation from the first commit rather than being moved across at the end. The only things that do not transfer are general know-how and reusable internal tooling that existed before your project, plus third-party open-source components, which stay under their own licences — that is normal and true of every software project, and we list what we used in the handover.

You do, and we set it up that way deliberately on day one. The cloud project, the database, the analytics property, the error-monitoring account, the domain and the app store listings are created under your company identity, and we work inside them with our own access. Nothing is registered in our name and then reassigned later. The reason is simple: an agency holding your production accounts has leverage over you, and we would rather not have any.

You keep everything and we get out of the way. Because the repository and the accounts were always yours, there is nothing to migrate — we revoke our own access, hand over any credentials we hold in a secure transfer, and provide the architecture and deployment documentation so the next engineer can pick it up. We will also answer reasonable handover questions from whoever takes over. There is no clause in our agreement that makes leaving expensive, because nothing good is built on a lock-in.

Yes, and we think you should have someone doing it. Operating systems release yearly updates that break things, platform APIs get deprecated on the vendor timetable, security patches for dependencies arrive continuously, and real users find the bugs the test plan missed. A maintenance retainer covers monitoring, updates, fixes and a share of time for small improvements. If you would rather bring it in-house, we will hand over clean documentation instead — but do not let it drift with nobody responsible.

They should be registered to your company, not to us, and we will walk you through it. Apple charges an annual fee for its Developer Program and Google charges a one-time registration fee; both are paid directly by you, and Apple in particular requires business verification that can take time, so we start it early. We then get added as team members with the access we need to build and submit. If those accounts are currently in a previous developer name, transferring them back is one of the first things we deal with.