What you can ask for, and what we will turn down.
Most people get in touch unsure whether their problem counts as the sort of thing software can fix, or whether they are supposed to know what to ask for. These are the questions that come up before the first conversation.
Before you write to us.
I don't know what I want built. Is that a problem?
No, and it is the usual starting point. Describe the task that irritates you, in the words you would use to explain it to somebody new on their first day. Working out what the software should be is our job, not yours, and it is most of what you are paying for.
How much detail do you need in a first message?
A sentence or two. "Our office manager spends every Monday morning retyping delivery notes" is enough to start a useful conversation. If you can add roughly how often the job happens and how long it takes, better still.
What should we have ready for the first visit?
Whatever the job currently runs on — the spreadsheet, the paper form, the folder of files — and, most importantly, the person who actually does it. Half a day watching the work being done tells us more than any amount of describing it.
Are you going to try to sell us something bigger?
No. The whole approach is one job at a time. If we think your problem is larger than one tool, we will say so and quote the parts separately, so you can do one and stop.
Reasonable things to ask for.
What sorts of things do you actually build?
Tools that remove one repeated job. Converting or checking files against rules that really apply. Reading paperwork and turning it into structured records. Giving everyone one place to see where work has got to. Calculating something the same way every time. Forecasting or scoring from your own history. The services page goes through these properly.
Can it work with the software we already use?
Usually. If your system allows other software to read or write data, we can connect to it. If it does not, we can often work from the files and exports it produces instead. We establish which before quoting, not after.
Our records are a mess. Can you still help?
Yes, and it is a common starting point. Pulling scattered records into one set that everyone trusts is a job in its own right, and occasionally the only one worth doing first. We will tell you plainly whether your data supports what you are hoping for yet, and if not, what would need recording from now on.
Do we actually need AI for this?
Often not, and we will say so. Plenty of jobs are solved by careful ordinary software, which is cheaper and more predictable. AI earns its place when something has to be read, predicted or judged rather than simply calculated. You are buying the result, not the technology.
Can you build something for one person, or does it need to be for the whole company?
One person is fine. Some of the most worthwhile tools are used by a single member of staff for an hour a day. The test is whether the job is repeated, not how many people do it.
Where we will say no.
Saying this up front saves you a conversation. We would rather turn work down than take it on badly.
Will you build us a customer-facing app or website?
No. We build tools for the people inside your business. Anything the public uses needs design, marketing and support around the clock, which is a different kind of firm from this one.
Can you replace our accounting, payroll, CRM or stock system?
No, and be wary of anyone who says yes. Those products already exist, they are good, and they cost a fraction of anything built from scratch. If your enquiry turns out to be one of these, we will tell you which product to look at and charge you nothing for it.
Can you take over software somebody else built for us?
Rarely. Inheriting a half-finished system usually costs more than building the one job again properly, and the result is worse. We will look at it and tell you honestly which of the two applies.
Do you offer round-the-clock support?
No. We answer within four hours on a working day. If a job is so critical that an hour of downtime costs you real money, you need a supplier with a team behind it, and we will say so rather than take the work and hope.
Can you handle card payments?
No. Taking payments brings compliance obligations that belong with specialists. We do build tools that hold confidential records, with access limited by role and a trail of who changed what.
Can you promise what the forecast will be worth?
No, and nobody honest can. What we can do is test a model against what actually happened in your business and show you how it would have performed. If it would not have helped, we say so before you spend anything on building it.
What happens once it is built.
How much of our time will this take?
Half a day at the start, an hour or so in the middle to look at progress, and a session at the end to train whoever will use it. Very little in between — we build against your real files rather than asking you questions every week.
Who owns the tool when it is finished?
You do. The code and the data are yours. If you stop the monthly fee you keep everything, and you are free to take it to somebody else.
What if the business changes and the tool no longer fits?
That is what the monthly fee is for. Businesses change, and a tool that cannot change with them quietly stops being used. New requirements get built in as they come up, and models get retrained as fresh data arrives.
Does our data leave the business?
Only where the job genuinely requires it, and we tell you exactly where before anything is built. A good many of these tools run entirely on your own files with nothing going anywhere.