The Awkward Questions, Answered Before You Ask Them
Twenty-five questions UK buyers put to us on first calls — including the ones about time zones, VAT, payment terms and what happens to your data — answered the way we would answer them on the phone.
Jump to a Section
Before There Is a Contract
What the first conversation produces, how much notice we need, and how to protect the idea before you describe it.
Is the free estimate a quotation I can put in front of a board?
Not yet, and the distinction matters. The free estimate is a written scoping document: a proposed shape for a first release, a week-by-week delivery window and a sterling range excluding VAT, with the assumptions it rests on written underneath so you can see what would move the number. It is genuinely free, it is yours to keep, and you are welcome to take it to another supplier. A quotation is the next step — a firm figure we hold, issued once the scope has been pinned down in detail and referenced by a signed engagement letter. Boards generally want the quotation; the estimate is what tells you whether the project is worth taking to the board at all.
How much notice do you need before a team can start?
Design work on a new engagement typically begins one to two weeks after the engagement letter is signed, with build starting once screens are approved. Triage work moves faster: if you have a production system down, a store rejection or a contractor who has just stopped answering, say so in the first message and we will look at it within days rather than weeks. We would rather tell you we have no capacity until a given month than accept the work and quietly queue it, because a supplier who has taken your deposit and not started is a worse position to be in than one who said no.
What is the least I can send and still get a useful number back?
A few paragraphs of plain English. What the software is meant to change about how your business runs, roughly who uses it, whether anything already exists, and any integration or compliance constraint you already know about — a specific accounting package, a regulator, an accessibility requirement because you sell to councils. That is enough for a range. Wireframes, a feature list or a competitor to point at will narrow it further. You do not need a specification document, and a specification written without an engineer in the room usually has to be redone anyway.
Will you sign a mutual NDA before I describe the idea in detail?
Yes, at no cost and without conditions. There is a checkbox on the contact form to request one, and if your solicitor has a preferred form we will normally sign yours rather than insisting on ours. Two practical points. Assume the first email you send is not yet covered, so keep it to a sentence or two until the document is executed — a one-line description is always enough to open a conversation. And under UK law an assignment of copyright has to be in writing and signed to be effective, so the NDA and the assignment clause in the engagement letter are doing two different jobs and you want both.
Do you work with sole traders and pre-incorporation founders, or only limited companies?
Both, with one caveat worth raising early. We can contract with a sole trader or an individual, but the ownership arrangements we recommend — repositories, cloud accounts, developer programme memberships and domains registered to the business rather than a person — are considerably tidier once there is a limited company at Companies House to register them to. Apple in particular requires business verification for a company developer account and that takes time. If you are mid-incorporation, tell us and we will sequence the account setup so nothing has to be transferred out of a personal name later.
Hours, Visibility and Who You Actually Deal With
The time zone question answered without spin, plus how you check progress rather than take our word for it.
Your team works Indian hours. What does that mean for my day?
It means your morning is properly covered and your late afternoon is not. Indian Standard Time runs four and a half hours ahead of UK time, so the team is at work through roughly 9am to early afternoon UK. Calls, design reviews and anything needing a decision get booked in that window, and questions asked before lunch are usually acted on the same day. From around 4pm UK the team has finished. We commit to a written update at the close of every working day, a reply to anything you raise within one business day, and a build you can install every fortnight. We do not claim a UK office, a British-based delivery team or round-the-clock cover, because none of those would be true.
What is the latest I can send something and still get an answer the same day?
Realistically, about lunchtime. Something raised before roughly 1pm UK will usually be looked at that day and may well be in the evening update. Something sent at 4pm is read and answered the following morning — that is the honest limit of the arrangement and we would rather state it plainly than let you discover it during a bad week. Where a late response genuinely matters, for example around a release or an investor demo, we agree that date in advance and arrange cover for it. A support retainer can also set a defined out-of-hours escalation route, priced separately.
How do I check progress without simply taking your word for it?
By opening the build. Every fortnight there is something you install on your own phone or open in your own browser, and thirty seconds with it tells you more than any report. Alongside that you get the daily written note covering what moved, what is next and what is blocked, and because the repository is in your company name you can see the commit history yourself or hand a read-only invitation to an adviser. If you want a third party to review the code mid-engagement, we will help arrange it rather than resist it.
Who am I actually speaking to week to week?
The people doing the work, not an account manager relaying messages. On a typical fixed-scope build you deal with a lead engineer who owns the technical decisions and a designer during the design phase, with specialists pulled in for particular pieces. Calls in the overlap window are with those people. We would rather you have a slightly awkward direct conversation with the engineer who made a decision than a polished summary from someone who did not. If the team changes mid-engagement you are told in the daily update, not after the fact.
I have changed my mind halfway through a sprint. What happens now?
Expect to change your mind — using a real build always generates better ideas than reading a document did, which is rather the point of shipping one every fortnight. Small adjustments inside the agreed scope are absorbed as we go without a conversation about money. Anything that adds real work gets a short written change note: what it is, what it costs excluding VAT, and what it does to the delivery date. You then decide whether it goes in now, moves to a later phase, or is dropped. Nothing starts until you have said yes in writing, which is the entire mechanism.
What We Take On and How We Choose the Stack
The work we decline, the design question, inherited code, and how we fit alongside people you already employ.
Is there a category of software you will not take on?
We build across mobile, web, SaaS, desktop, backend and APIs, AI-enabled features, ecommerce, dashboards, browser extensions and companion apps for connected hardware, so the refusals are rarely about technical range. What we decline is work where the budget cannot support the scope and no smaller version would be worth having, work an off-the-shelf product would do properly for a fraction of the money, and work carrying a regulatory burden that genuinely needs an audited specialist — certain FCA permissions or clinical safety cases under DCB0129 are the usual examples. We will also decline anything designed to mislead the people using it.
I already have a designer. Do you insist on doing the design yourselves?
No. We are happy to build from designs you already own, and we will review them before quoting and flag anything that will be expensive or awkward to implement — an interaction that fights the platform conventions, a layout that will not survive a 320-pixel-wide screen, a colour pairing that fails WCAG 2.2 AA contrast and will cause you trouble if you sell to the public sector. Where there is no designer, we do that work ourselves and produce a clickable prototype you sign off before production code exists, because moving a button in a prototype costs minutes.
My previous developer left a codebase nobody understands. Where do you start?
With a fixed-price audit rather than an opinion. We read the code, map the architecture and the data model, check the dependencies and their known vulnerabilities, look at how it is built and deployed, and try to stand it up from a clean checkout — which is often where the first real problem surfaces. You get a written verdict on whether continuing is genuinely cheaper than rebuilding over the next twelve months, with reasons, and sometimes that verdict is that a rebuild costs less. The audit is yours whether or not you go on to engage us for the work.
How do you decide which language and framework to use?
The project decides, not a house preference. Cross-platform frameworks such as React Native or Flutter make sense where one codebase can serve both mobile platforms and the app is not leaning hard on device hardware; native Swift or Kotlin makes sense where it is. On the server we work with mainstream, well-supported choices — JavaScript and TypeScript, Python, PHP, relational databases and the major cloud providers — and we avoid obscure stacks deliberately. The test we apply is whether a competent engineer who has never met us could pick your project up. If the answer is no, the choice is wrong however elegant it looks.
Can you work as an extra pair of hands alongside my in-house developer?
Yes, and it is a common arrangement. We will take a defined piece — the mobile app, an API, a specific integration, a migration — and work to your repository conventions, your review process and your ticket system rather than importing ours. What we ask for in return is a clear boundary of who owns which part of the system and one named person on your side who can settle a disagreement. Shared ownership of the same component with no boundary is reliably how integration work turns into two teams blaming each other.
Figures, VAT, Invoicing and What Sits Outside the Price
Everything a finance director asks in the second meeting, answered before the first one.
What is a realistic budget for a first release in sterling?
Most first versions land between roughly £8,000 and £55,000 excluding VAT. What moves the figure is the number of platforms, the count of genuinely distinct screens, and whether the expensive pieces are in scope — card payments or Direct Debit, real-time updates, an admin back office, offline working, or an integration with a system that was never designed to be integrated with. The cost calculator gives you an indicative range in about a minute and we confirm a real figure after a scoping call. A number quoted before anyone understands the scope is a guess in a suit.
Are the figures you publish inclusive of VAT?
No. Every figure on this site, in the calculator and in a proposal is stated excluding VAT, and VAT is added on the invoice at the prevailing rate where it applies. We publish ex-VAT figures because our buyers are almost always VAT-registered businesses that will recover it, so the ex-VAT number is the one that reflects the real cost to them. If you are not VAT registered — some charities, some small operations below the threshold — tell us early, because the VAT is then a genuine cost to you and should be in the budget you are planning against.
How does invoicing work and what are your payment terms?
Fixed-price work is invoiced against milestones written into the engagement letter before anything starts: a deposit to begin, payments tied to design sign-off and to named build milestones, and a final instalment on delivery. Monthly arrangements are invoiced monthly in advance. Standard terms are 30 days from the invoice date, we can quote a purchase order number on the invoice where your procurement requires one, and payment by bank transfer is simplest. Late payment on a business-to-business contract carries statutory interest and a fixed recovery sum under the Late Payment of Commercial Debts legislation; we would always rather ring you than invoke it.
Fixed price or a monthly team — which should I be asking for?
Fixed price suits work whose scope can be pinned down before it starts: a first release, a defined feature set, a migration with a visible finish line. You get budget certainty and we carry the risk of having estimated badly. A monthly dedicated-team arrangement suits work where the roadmap is genuinely going to move — continuing product development, a platform with a long life, a research-heavy problem where the answer changes the plan. The usual advice is fixed price for the first release and monthly afterwards. Asking for a fixed price on work nobody can scope yet produces a padded number or a fight, and often both.
What costs will I be paying that do not come to you?
Third-party costs, which we pass through rather than mark up and list in the proposal with realistic figures. Typically: the Apple Developer Programme annual fee and the Google Play one-off registration fee, cloud hosting and its data transfer, domain and certificate renewals, paid APIs and services such as SMS, mapping, address lookup, email delivery or identity checks, payment processing fees from Stripe, GoCardless or your acquirer, premium fonts and stock media, and any commercial software licence the build needs. Maintenance after the defect-fix window is a separate retainer rather than an assumption.
UK GDPR, Residency, Agreements and Ownership
The questions a data protection officer, an information governance lead or a procurement team will ask you about us.
How does UK GDPR actually change what you build?
It changes the design, not just the policy page. Before screens are drawn we work out what personal data the system genuinely needs rather than what would be nice to have, which lawful basis each processing activity rests on, how long each category is kept and what happens at the end of that period, and how a subject access or erasure request will be serviced in practice rather than in principle. That usually means real features: an export, a delete that also clears the backups schedule, an audit trail, role-based access so staff see only what their job requires. Retrofitting those after launch is a migration; designing them in is a conversation.
Where will our data physically be stored?
Wherever you need it to be, decided before we build rather than after. The major cloud providers all offer UK regions, typically London, and EU regions in Ireland and Frankfurt, and we will pin your databases, object storage, backups and logs to the region you specify. Be aware that the region choice has to extend to the supporting services too — a managed search index, an email relay, an error monitoring tool or an AI model endpoint sitting in a different jurisdiction will quietly undo the decision. We list every third-party service the build touches and where it processes, so your records of processing can be accurate.
Will you sign a data processing agreement?
Yes. Where we process personal data on your behalf you are the controller and we are the processor, and Article 28 of the UK GDPR requires a written agreement with specific terms in it. We will sign yours if you have one, or provide one covering the usual ground: the subject matter and duration of the processing, the categories of data and data subjects, our obligation to act only on your documented instructions, confidentiality, security measures, the rules for engaging sub-processors, assistance with data subject requests and breach notification, and what happens to the data at the end. If personal data is processed outside the UK, the agreement carries the transfer safeguards too.
Who owns the code, the repositories and the store accounts at the end?
You do. Intellectual property in the software written for you is assigned to you on final payment, and because UK law requires an assignment of copyright to be in writing and signed, that assignment sits in the engagement letter rather than being assumed. The repositories, the cloud project, the error monitoring, the domain and the app store listings are created under your company name from week one, so there is nothing to migrate at the end. What does not transfer is general know-how and internal tooling that predates your project, and third-party open-source components, which remain under their own licences — that is true of every software project and we list what was used in the handover.
If we stop working together, what do I have to do to keep running?
Very little, by design. Because the accounts were always yours, there is nothing to hand back — we revoke our own access, transfer any credentials we hold through a secure channel, and provide the architecture and deployment documentation the next engineer needs. We will answer reasonable handover questions from whoever takes over, and we will delete or return your data as the processing agreement specifies. There is no clause in our engagement letter that makes leaving expensive, because nothing worth building rests on a supplier being difficult to replace.
Put These to Every Supplier You Shortlist, Including Us
None of them are technical. All of them are questions a supplier planning to behave badly finds difficult to answer in writing.
Something Here We Have Not Covered?
Ring us, message us on WhatsApp, or put it in writing — anything you raise gets a reply within one business day, and we would rather answer an uncomfortable question now than after you have signed something.