These aren't the questions a marketing team thinks you'll ask. They're the ones businesses asked us on real calls, in their own words, before they bought anything. Short answers here. Each one links to the longer version on the blog.
Asked on nearly every first call, usually carefully.
Asked on a call: "If this is what we want, then how much would it cost roughly?"
We don't publish build prices, because the number is driven by how much ambiguity is left when we start, and that's different for every business. What we do publish is the cost of finding out. A Targeted Discovery is £2,600 and takes one to two weeks on a single process. An In-Depth Discovery is £7,100 and takes two weeks across the whole operation. Both end with a fixed price for the build and a document you could take to any other supplier.
The better question is what the problem costs you a year. Hours a week, times a loaded rate, times 46 weeks. Any quote should be measured against that.
Read the full answer →Asked on a call: "If I'm talking about two years down the line and you've got this tool, is 55k a good investment or a bad investment?"
Take the baseline before anything is built: hours a week, days to turn a quote, errors last month. Afterwards everyone remembers the old way as either much worse or much better than it was. The measure we care about most is adoption in week eight. Everything else is theoretical if nobody opens it.
Read the full answer →Asked on a call: "I didn't have that sort of clear conversation with him, saying how much is this going to cost to maintain."
Three separate things. Running costs (hosting, database, AI usage) in your name, at cost, with the receipts. Support, with a written response time. And change, because your business will move and the software has to follow. All three are itemised before you sign. No lock-in on any of it.
Read the full answer →Fixed price per phase, almost always. Day rate puts the risk on you; fixed price puts it on us, and we've absorbed it before. Fixed price is only possible after discovery, because we can't fix a price on a description. Anyone who offers one without discovery has either padded it heavily or will be back for more.
Read the full answer →Two kinds. Targeted Discovery, £2,600: one to two weeks on a single process. In-Depth Discovery, £7,100: two weeks across the whole operation. Either way we interview the people who do the job, not their managers, watch the process happen, and score every opportunity by impact and effort with a named source against each. You get a document you could take to another supplier and get a sensible quote from. If it only works if we do the build, it was a brochure.
Read the full answer →The questions people ask twice when the first answer was vague.
Asked on a call, twice: "Where is our data going to be stored if we were to work with you?"
In infrastructure you own or rent, in a region you choose, under an account with your name on the invoice. If we parted company tomorrow you'd keep everything without needing our cooperation. A well-built system sends the AI the minimum it needs for the job and nothing else. Summarising one order doesn't need your customer list.
Read the full answer →Asked on a call: "If you give all your CRM data to something like OpenAI, like ChatGPT, what can anybody do about that?"
On business API tiers from the major providers, no. Your data isn't used for training by default, and enterprise agreements make that contractual. That's different from consumer chat apps, where the terms are written for individuals. The real risk in most businesses is staff using consumer tools on their own logins because the sanctioned route doesn't exist. Give them one.
Read the full answer →Asked on a call: "How would that work in terms of GDPR?"
GDPR doesn't care that it's AI. The rules cover processing personal data, and they apply the same to a script, a spreadsheet or a language model. What needs doing: know your lawful basis, have a data processing agreement with everyone who touches the data (including us and the AI provider), send the minimum, and keep a record of what the system did. Not legal advice, just what we've had to get right.
Read the full answer →Overheard on a call: "Why don't I own the report?"
You paid for it, you own it. Code, data, documentation, and anything produced while thinking about your business. The practical test is whether you could get a full export and hand everything to another developer without ringing us. Ownership you can't exercise without permission isn't ownership.
Read the full answer →You do, in accounts in your name, billed to you. We set them up and manage them; the name on the invoice is yours. If your systems ran in our account, every conversation about money would have a hostage situation underneath it. Neither of us wants that.
Read the full answer →Yes, routinely, and we have a mutual one ready if you don't. Anyone working on your project is under the same obligations, back to back. We'll push back on a non-compete covering your whole sector, because we work with energy, construction and industrial businesses and couldn't otherwise work at all.
Read the full answer →What goes wrong, and what happens then.
Asked mid-demo: "Did this hallucinate or what?"
It will, sometimes. Anyone telling you otherwise is selling. The design question is what being wrong costs and how fast you find out. Drafting an email a human sends: cheap, obvious. Posting a figure into your accounts unsupervised: expensive, invisible, and we won't build it. Citations, a confidence threshold that escalates to a person, and a log of every run.
Read the full answer →Asked on a call: "You said you're a one-man band, so what happens when you're on holiday and we need support?"
Your infrastructure is in your accounts, your code is in your repository, and it's documented for a stranger, so any competent developer can pick it up. There's a bench, and for anything critical someone other than Rishi knows how it works. We're not a 24/7 rota, and if you need one-hour response at 3am we're the wrong supplier and we'll say so. What you get is a defined response time in writing.
Read the full answer →One of the commonest ways good software quietly dies. The defences: write down the why as well as the how, make sure more than one person can explain it to a new starter, and make the system load-bearing so the old spreadsheet stops being an option. If a build is really one person's project, better to notice that during discovery than after they resign.
Read the full answer →Yes, and it's more common than the industry admits. First questions: do you have the code, in a repository in your name? Are the hosting and domain accounts yours? Is it running? Sometimes the right answer is to inherit the working parts and rebuild one area, and we'll show the reasoning rather than just quote a rebuild.
Read the full answer →That should be possible on any Tuesday, without a negotiation. Everything's already in your accounts, so there's nothing to transfer. We do a walkthrough with whoever's taking it on and hand over documentation written for a stranger. More than once the in-house team has taken the day-to-day and called us for the next new thing, which suits everyone.
Read the full answer →Rarely asked by the person paying. Always in the room.
Asked on a call: "What would you do with the five hours if you had it?"
In everything we've delivered, the work that disappeared was work nobody wanted: re-typing an order that already existed in an email, building the same report every Friday, ringing round to find a part. If a role is made entirely of the work we're automating, that's a real conversation and it belongs to you, before the build. Ask your team what they'd do with the hours. Their answer tells you which project you're running.
Read the full answer →We do, and it matters less than what happened before it. If the people who use it were interviewed and shown something early, training is a formality. If they hate it, something's wrong and it's cheap to fix in week one: usually it's slower for the one case they do most, or it removed a step they used as a check, or nobody explained why.
Read the full answer →About an hour each from the people who do the work during discovery, an hour a fortnight for review during the build (same person each time), and half a day per team at go-live plus a fortnight of someone being available for "how do I" questions. That last part is where confidence forms, and skipping it is the surest way to waste a build.
Read the full answer →Alongside them. Keeping your business running is a different discipline from building software that didn't exist before. We want them introduced during discovery, not discovered at handover, and if they want to take over support afterwards we'll document it for them properly.
Read the full answer →Yes, often the best arrangement. Settle one thing first: who decides when there's a technical disagreement. Their code standards apply in their repository. If your developers wanted this project and were told no, say so before we arrive; sometimes the right answer is that they build it and we scope it.
Read the full answer →From the first call to something in real hands.
Asked on a call: "We gave it a go-ahead to discovery and write some software, how long does that take?"
Discovery: two weeks, and we hold that line. First usable phase: six to ten weeks after sign-off, depending on integrations. What actually causes delay is almost never the code. It's a login nobody can find, a decision that needs someone on holiday, and feedback rounds where you're busy running your business. We plan around the time you can actually give.
Read the full answer →Yes, and we'll often argue for it even when you arrive ready to spend more. You don't yet know whether we're any good; a small first phase is the cheapest way to find out. Small means one process, in real hands within weeks, and useful on its own even if nothing else ever gets built.
Read the full answer →You will, usually for good reasons. Anything outside the agreed scope gets written down with what it does to time and cost, then you decide: now, later or never. Most mid-build ideas get "yes, and that's phase two", because scope creep sinks adoption before it sinks budgets.
Read the full answer →Automated tests, a staging environment with realistic data, deliberate failure testing. Then the one that catches things: a person who's never seen it doing their real job with it while someone watches and says nothing. Sign-off comes after somebody who'll actually use it has tried, unaided, and succeeded.
Read the full answer →Asked on a call: "Someone's going to audit me at some point."
The working system in your infrastructure. The code in a repository in your name. Owner access to everything. Technical documentation for a developer who's never met you, a user guide for what's live now, a record of the decisions, and a business continuity note: what to check first if it stops.
Read the full answer →The healthiest possible starting point. You don't need a solution, you need to be able to describe a bad day: what went wrong, who fixed it, how long it took. Ask yourself which report someone builds by hand, and what would break first if you were off for a fortnight. Sometimes the answer at the end is that you don't need software at all, and we'd rather say that.
Read the full answer →Off the shelf, ChatGPT, and how to tell who's any good.
Asked on a call: "Why are we spending so much money on software where we could just have something off the shelf that costs a few hundred quid a month?"
Often you should, and we've talked people out of builds with exactly that reasoning. Buy when your process is normal and you can live with changing how you work to suit the tool. Build when the process is the reason customers choose you, or when you've already bought the tool and built a spreadsheet next to it to make it usable. Usually the answer is buy the boring parts and build only the piece that's yours.
Read the full answer →Sometimes you should, and we've said so on calls where it cost us the work. It stops being enough when the system has to know your business, has to run without anyone remembering, has to write back into your other systems, or has to leave an audit trail. If a competent person with a chat window could do it in five minutes, don't build anything.
Read the full answer →It depends on the job, and we'll tell you which and why before we build. What matters more than the model is what you send it and whether you can switch. Systems should be built so the model is a component, not a foundation. The question worth asking is: if this provider doubled its price next year, what would we have to do?
Read the full answer →Automation is rules: when this happens, do that. Cheap, identical every time, breaks loudly. AI is judgement over messy input: reading an email, extracting data from an invoice with a different layout each time. It costs more and is occasionally wrong in ways that look right. A lot of what's sold as AI is a rule with a language model bolted on for glamour. Most real systems are mostly rules with AI at the two or three points where judgement is needed.
Read the full answer →Ask what they've talked a client out of. Ask about one that went wrong and listen for whether they take any responsibility. Ask where your data will be and whose account holds it. Ask what it costs to run. Ask what happens when it's wrong. Ask to speak to a client nine months in, not one who just launched.
Read the full answer →Headcount is the wrong measure. What predicts a good project: one person can say yes, the problem is worth more than the fix, and somebody will own it. Two people and a twenty-minute weekly process: keep the spreadsheet. Six-month procurement needing a supplier with two hundred staff: we're the wrong shape.
Read the full answer →Anything needing a live AI response needs a connection at that moment. Anything recording, looking up or working through a job can be built to work offline and sync when signal returns. It costs more and it's usually worth it. We've shipped a training package as a single offline file precisely because meeting-room wifi can't be trusted.
Read the full answer →Yes. Clients in the UK and the United States. What differs is what counts as evidence, and the practical things: agree the currency and who absorbs conversion before the first invoice, define your hours and say so, and always ask for a date. A time zone with no working-hours overlap is where we'd say no.
Read the full answer →Your question isn't here? Twenty minutes minimum, seven questions, and a one-page Bottleneck Blueprint within 48 hours. If it's not a fit, we'll say so on the call.
Book a call