The Internal Tool That Became a Product: A Pattern Worth Knowing
Apparatus built Codex and Authentic to solve its own problems. Both are now products other firms pay for. The pattern is more common than it looks.
The clearest way to understand what custom AI development can look like is to look at specific examples. Not case studies with client names removed and vague outcomes reported. Actual tools with actual origin stories.
Apparatus built two products this way: Codex and Authentic. Both started as internal tools built to solve problems we were running into ourselves. Neither started with the intention of becoming something we would sell. Both did, because we found out that other firms in our space had the same problem and nothing on the market was solving it either.
Codex: the onboarding problem
The problem Codex was built to solve is familiar to any firm that has grown past the point where the founders can personally onboard every new hire. Knowledge transfer in professional services is harder than it looks. The SOPs exist. The handbooks exist. New team members read them. And then the first real engagement arrives, and it becomes apparent that reading about how the firm works is not the same as knowing how the firm works.
The gap shows up in small ways that accumulate: the way a deliverable gets structured, the specific questions that get asked in a client discovery call, what gets flagged versus what gets noted versus what gets ignored. None of it is in the handbook. It was never written down because the people who know it learned it by doing it.
The usual fix is to have a senior person run the new hire through things in person. This works. It also requires the senior person to be available and willing to run it each time, which means it happens inconsistently, gets compressed when they are busy, and varies based on whoever happens to be around.
Codex replaced that dependency. It is a Slack and email-based system that runs through the firm's SOPs in a structured way - not as documents to read, but as questions to answer. New team members get quizzed on the material, get feedback on their responses, and the system tracks where gaps remain. No one needs to run the session. No one needs to be available. The system handles it, and anyone with access to the results can see exactly where a new hire's understanding is solid and where it needs more attention.
The product came out of a simple realization: every firm we talked to had the same problem and was solving it the same inadequate way - by depending on whoever had time to run an ad hoc session. The market had no good solution for firms at our scale. So we productized what we had built for ourselves.
Authentic: the relationship management problem
Authentic started from a different frustration. Every CRM on the market was built for sales funnels - thousands of leads, automated follow-up sequences, pipeline tracking. That is a real problem for companies with a large number of prospects moving through a defined process. It is not the problem most professional services firms have.
Our actual relationship management challenge looked like this: roughly one hundred relationships that genuinely matter. Partners, clients, referral sources, people we want to stay in real contact with. Not leads. Not people to drip market to. People where the relationship has actual texture - context about what they are working on, what has changed in their lives, what we last talked about, when it makes sense to reach out again.
Every CRM wanted to automate the outreach. That is exactly the wrong instinct. An automated birthday message from a consulting firm is worse than no message at all. What the work actually required was the opposite of automation: a system that tracked context and surfaced it at the right moment, so that when someone reached out, they did it with actual knowledge of what was going on with that person.
Authentic does that. It tracks context from past interactions, notes life events and professional milestones that matter for relationship quality, and suggests when an outreach makes sense and why. It never sends anything automatically. The person still decides, still writes the message, still chooses whether to reach out at all. The system does the work of remembering, so the person can focus on the quality of the contact.
The key insight behind Authentic was that the firms in our space were not managing thousands of relationships badly. They were managing one hundred relationships at lower quality than they should have been, because the tools available were built for a different problem. The right product for that situation looks nothing like a CRM.
The pattern behind both
Looking at Codex and Authentic together, the pattern is the same in both cases. We had a specific operational problem. We looked at what the market offered. The market offerings were either built for a different scale, a different industry, or a different version of the problem. We built something for our actual situation. Then we found out that other firms had the same situation.
That last part is the key test. Not every internal tool becomes a product, and most should not try. A tool built for a quirk specific to your firm - a particular client relationship, an idiosyncratic internal process, a one-off need - is useful internally and not worth productizing. The tools that become products are the ones where the underlying problem is shared across the industry, just not served well by what is available.
The signal is usually when you describe your tool to peers and they say some version of "we have that same problem and we are handling it the same terrible way." That is when you know you built something for yourself that also happens to be something others would pay for.
What this means for firms building their own tools
Most firms building internal AI tools are not building with the intention of productizing them. That is fine. The internal value is real regardless of whether a product ever emerges. But the pattern is worth knowing because it suggests something about how to identify which tools are worth building: the ones that solve problems you share with others in your industry are better investments than the ones that solve problems unique to you.
A tool that automates a workflow specific to how your firm handles one client is worth less, in pure economic terms, than a tool that automates a workflow every firm like yours runs. The first solves your problem. The second solves an industry problem and happens to start with your firm's version of it.
The best internally-built tools often start with something very specific - one workflow, one team's actual pain point - and turn out to generalize more than expected. Figuring out which workflow to start with is worth doing carefully. The right starting point usually sits at the intersection of high internal value and recognizable industry-wide problem.
If you have an operational problem that you are solving poorly - with manual processes, with dependencies on specific people, with tools built for someone else's version of your problem - that is a conversation worth having. The 303 engagement starts with exactly that kind of problem and works through to a tool that actually solves it.