What Building Our Own App Taught Our Consultancy

Most of our work is building and looking after technology for other people. A client brings a problem, we agree a scope, we build it, and we hand it over. We do that for businesses and charities, and we have over 20 years of experience doing it.

Phonic is different. It is our first app. It records and transcribes on iPhone, iPad, Mac and Apple Watch, and nobody commissioned it. There is no client to agree the scope with, no sign-off meeting, and no handover. Every decision is ours, and so is every consequence.

This post is about what that changes, and what it means for the advice we give clients.

Being on the other side of the table

When we work for a client, we spend a lot of time asking questions. What does this need to do? Who uses it? What happens when it goes wrong? We wrote about this in how software actually gets built, and the point of that stage is to stop people building things they do not need.

With our own product, nobody else asks those questions. We have to ask them of ourselves, and it is much easier to wave your own answers through.

Scope is the obvious one. On a client project, scope is written down and agreed, and anything new is a conversation about time and money. On your own product, every idea feels reasonable and there is nobody to push back. The discipline has to come from inside the team.

Pricing is another. We give clients a clear scope, timeline and cost. Pricing a product is a different kind of decision. Phonic is free to download, and Phonic Pro is a one-off £2.99 in-app purchase that adds speaker identification, system audio from apps like Teams and Zoom, Meeting mode and the Insights tab. The free version records, transcribes, searches and exports. Deciding where that line sits is a product decision, not a technical one, and there is no client to make it for us.

Support is the third. On client work, support is a retainer or a handover. Once your own app is out, there is no handover. Whoever uses it is our customer, and nobody else is going to answer their questions.

Writing honest help articles

Phonic has a support site with help articles and release notes. Writing it was a useful exercise, because a help article has nowhere to hide.

It is tempting to describe only what the product does well. The more useful articles describe where it stops. A few examples from the Phonic help pages:

• Search matches whole words and word prefixes. It does not find text in the middle of a word, and it works less well for languages written without spaces. That is stated plainly in the search article.
• On the Mac, macOS cannot report whether System Audio Recording permission is turned on. Without it, other apps record as silence. That article explains the problem and where to fix it.
• Recordings up to an hour use the Sortformer speaker model. Longer ones use clustering alone, which can merge similar voices. The speaker naming article says so.
• iOS ends Live Activities after 8 hours. A longer recording carries on without it, and has to be stopped from the app. There is an article for that too.

None of these are flattering. Each one saves a user from wondering whether something is broken. We push clients to document their systems properly for the same reason: the next person should not have to guess. It feels different when the reader is your own customer and the gaps are your own.

Privacy as a design decision

We give clients advice about data protection regularly. With Phonic, we had to make the decisions ourselves, for a product that records conversations.

The design is simple to describe. Recording and transcription happen on the device, using Apple’s speech models. With Phonic Pro, speakers are identified on the device too. Phonic does not ask you to create an account with us. Each recording is a package in the user’s own iCloud Drive, visible in Files and Finder, and without iCloud it stays in a Phonic Library on the device. The privacy policy sets this out in full.

What that means in practice is that the recordings are files the user controls. They can move, export or delete them at any time. Transcripts export as Text, Markdown or SRT.

The general lesson for any business is that privacy is much easier to design in than to add later. If the data never leaves the device, there is a lot less to secure, explain and answer for. That will not suit every product. Plenty of services genuinely need a server and an account. But it is worth asking early whether yours does, because the answer shapes everything after it.

There are trade-offs. On-device processing depends on what the device can do. The first transcription in a language downloads Apple’s speech model, and with Phonic Pro the first speaker identification downloads FluidAudio’s speaker models, about 120 MB. Those are one-off downloads, and the help article suggests doing it on Wi-Fi before a long meeting.

The same AI experience, on a phone

Our AI and machine learning work for clients covers things like document processing, internal search and automated reports. As our home page puts it, the same experience runs inside Phonic, on the device.

The Insights tab in Phonic Pro produces a summary, key points, action items with owners, decisions, open questions, topics with timestamps and talk time per speaker. It uses Apple Intelligence when it is available, with a built-in fallback when it is not.

Speaker naming is a good example of applying AI carefully. Speakers start as Person A, Person B and so on. Phonic names a speaker when they introduce themselves or are addressed by name, using the calendar meeting’s attendees when there is one. The user can rename speakers, with the attendees offered as suggestions. Until Phonic hears a name, a speaker stays Person A.

That is the same approach we take with clients. AI should do a specific job, the limits should be clear, and there should be a sensible fallback when it cannot help. Running it on a phone rather than a server adds constraints, but the principle is the same.

What it means for client work

Building a product ourselves has not changed what we tell clients. It has made us more aware of what we are asking them to do.

When we tell a client to budget for maintenance, we now carry that cost on our own product. Every new OS release, every library update and every support question lands with us. Our post on what technical debt costs applies to our own code as much as anyone’s. Shortcuts taken to ship sooner get paid back later, and on your own product you pay them yourself.

The same goes for documentation and privacy. We now have help articles that real users will judge us on, and a product where we made the privacy decisions ourselves rather than advising someone else on theirs.

If you are thinking about building a product of your own, or need help with the software development or AI side of something you already run, get in touch. We will give you an honest view, including where we think it will be harder than it looks.