You can now generate a working prototype of almost any piece of software in an afternoon. That should make building great vertical software easier. In reality, it doesn't.
Vertical AI is the term for AI-native software built for one specific domain, like tax, legal, healthcare or insurance, rather than a general tool meant to work everywhere. The software is built to understand that domain's workflows, edge cases and regulatory reality well enough to act inside it, rather than just answer questions about it. Tax software is one of the clearest examples of this growing software category.
The reason is that as the cost of writing code approaches zero, the quality of a product stops being determined by whether it can be built. It's determined by whether anyone involved knows what to build and has the judgment to leave out everything that doesn't belong.
3 principles that define good tax software
That shift changes what "Engineering" means inside a serious vertical software company. I'm seeing it every day at Fonoa.
1. Engineering means deciding what to build
This makes engineering more important, not less, because engineers are no longer mainly implementing a known specification. They're increasingly deciding, in real time, which workflows should disappear, where a system can safely act on its own, where a human still needs to stay in the loop, and what "correct" even means in a domain that should be deterministic, but realistically has always had some ambiguity because it lacks comprehensive testing.
Those aren't implementation details. They're some of the hardest calls a company makes, and they now sit with the people writing the code, not only the people writing the requirements document. We run multiple weekly calls where engineering, product and our tax lawyers work through exactly those calls together.
But that's one capability. It isn't sufficient on its own.
2. Taste decides whether it should exist
A second capability is harder to name and easier to underrate: product judgment, or taste.
Every domain accumulates decades of workflow that exists for one of two reasons: either a constraint that hasn't gone away, or a historical accident that nobody has bothered to question. Or both.
Telling the two apart is a skill. Just like it is a skill to know what to remove, what to simplify, and what an exceptional version of the product should feel like to use, vs a technically complete one. Engineering can answer "can we build it." Taste is what answers "should it exist this way at all."
As AI significantly drops the barrier to software development and more becomes technically possible, that second question gets harder, not easier. Companies that treat taste as an afterthought end up shipping technically impressive software that nobody particularly wants to use.
That used to be okay in many enterprise domains. Today, customers are increasingly demanding domain-specific software. And rightfully so.
3. Domain expertise gets more valuable, not less
The third capability is domain expertise, and it deserves more careful treatment than it usually gets in conversations about AI replacing expertise.
Deep knowledge of a domain becomes more valuable as models get more capable."
The questions that matter most, like which edge cases are real, which processes exist for a reason, and where the regulatory risk actually sits, require someone who has lived the problem in-house, not someone who has read about it.
But domain expertise carries a risk. Someone who has spent 20 years doing something a particular way can mistake the way they've always done it for the way it has to be done. Deep experience is exactly what makes a workflow feel inevitable, whether or not it actually is.
So the useful version of domain expertise in a vertical AI company isn't "ask the experienced professionals how to digitize what they already do." It's putting people who understand which constraints are real next to engineers and product thinkers willing to question every assumption anyway, including the ones the domain experts hold most confidently.
The question worth asking isn't how to automate the existing process. It's what the process would look like if you were inventing it today, with today's data, today's models, and no historical baggage.
Why the three capabilities multiply, not add
Put the three capabilities together and something interesting happens: none of them work particularly well alone.
Engineering without domain understanding produces technically elegant solutions to problems nobody has correctly diagnosed.
Domain expertise without engineering produces knowledge, or a consultancy, but not a scalable product.
Engineering and domain expertise together, without product taste, produce something powerful that's unpleasant to use. Taste without domain grounding produces something beautiful that solves an imaginary problem.
It's closer to a multiplication than an addition - engineering, AI capability, product taste and domain expertise reinforcing each other - because a serious weakness in any one of them drags the whole product down, no matter how strong the others are.
There's another important change happening: these no longer need to be separate people passing requirements to one another in sequence. AI increasingly lets a domain expert prototype, test and specify directly, to participate in building rather than only describing what should be built.
It also lets engineers get closer to the substance of a domain than a specification document ever made possible. The interesting organizational bet for us is to let those disciplines collide continuously, on the same problem, at the same time, rather than keeping tax people, product people and engineers in separate lanes with clean handoffs.
How this plays out at Fonoa
This is, in miniature, what’s happening at Fonoa.
We build TaxOS, an increasingly connected platform for enterprise indirect tax, and we've become more convinced over the past year that the biggest constraint on building it well was never access to capable models. It was assembling, in one place, people who have actually run global tax operations at serious scale, people who understand tax engines and tax infrastructure from the inside, and people with the product and engineering instincts to question everything those first two groups assume is fixed, and then getting all three groups to work on the same problems together, rather than trading documents between departments.
Three recent additions to our team are great examples of how this happens in practice.
Nikki Flom ran indirect tax for Meta, using Fonoa as a customer before deciding the more interesting problem was building the platform itself.
Roxna Nairani has spent her career building and scaling product at some of the fastest-growing, highest-velocity product companies operating today, including Meta, Instacart and Personio. She’s bringing a deep holistic understanding of what it takes to build a great product, with a conviction that product taste matters as much in enterprise as it does in consumer verticals.
Amine Tekfi spent years working on traditional enterprise tax engines and implementations at Thomson Reuters, and is now helping design what a tax engine looks like when it's built for an AI-native world rather than retrofitted for one.
And this is just the beginning. There are more great talent additions like these happening than we've talked about publicly so far.
The real edge in vertical AI
The broader comment isn't just about Fonoa. It's this: The vertical AI companies that will matter in a decade won't be the ones with the earliest access to the best models. It won’t be the ones that are fastest to use AI as a technology to ‘enrich’ product.
It will be the companies that worked out, before most of their competitors did, that domain experts becoming builders, not domain experts advising builders, was the actual unlock to great product and success.
