Why I built a product while running a services business

There is a piece of advice every founder hears: pick one. Build a services business or build a product. They pull in different directions, they reward different habits, and trying to do both means doing both badly.

I run a services business. Craftt does AI-native Attio implementations. I also ship a product, AttiBooks. Both are live right now.

So either the advice is wrong, or I am making the mistake it warns about. This is the honest version of why I think it is the first one, and the one rule I use to make sure it does not become the second.

What AttiBooks is

AttiBooks is an integration between Attio and QuickBooks. It lives at attibooks.com.

It does three things. It keeps your Attio companies and your QuickBooks customers in sync. When a deal moves to Won in Attio, it creates the invoice in QuickBooks. When that invoice is paid, the payment status flows back into Attio, so the people who closed the deal can see it without opening the accounting tool.

It shipped in three weeks. There is a free tier for under 100 records. That is the whole product.

It did not start as a product idea

Here is the part that matters. AttiBooks did not come from a whiteboard.

A client needed Attio and QuickBooks to talk. There was no native integration. I looked, the client looked, it did not exist. So I built the thing that did not exist.

I did not sit down to invent a product. I sat down to solve a problem that was already in front of me, attached to a real customer with a real reason to want it solved. The product was the leftover: once the thing existed, it was obvious other Attio users had the same gap.

This is the first reason the two businesses are not in conflict. The services work is what found the product. I would never have arrived at "Attio to QuickBooks sync" from a list of ideas. I arrived at it because a client walked me into it.

Why a services business alone has a ceiling

I like the services business. But it has a shape, and the shape has a ceiling.

A services business sells hours. Even a very good one, even one where most of the work is absorbed by agents and skills, still sells a finite amount of attention. When there is more demand, you serve it by adding people. More customers, more delivery, more headcount. The revenue climbs and the cost climbs with it, close to in step. I wrote about bending that curve with Claude Code, and it does bend. It does not disappear.

A product has a different shape. You build it once. The hundredth customer costs almost nothing more than the tenth. The revenue can climb while the cost stays roughly flat. That is the whole appeal, and it is a real one.

I am not leaving services. The services business is where the income is today, where the customer relationships are, and where the product ideas come from. But a business that only ever trades hours for money is a business with a ceiling I can already see. AttiBooks is how I work on the part with no ceiling, without walking away from the part that pays.

Why both is possible now

Ten years ago the advice to pick one was just correct. Shipping a product meant a team, a runway, and months before anything worked. You could not do that on the side of a services business. You had to choose.

That cost has dropped. AttiBooks went from a client's problem to a shipped product in three weeks, built by one person, because the tools for turning a clear specification into working software are not what they were. I build with Claude Code. The distance between "I know exactly what this should do" and "this is running" is now short enough that a services founder can cross it without shutting the services business down for a quarter.

The advice to pick one assumed the product would eat everything. When a product takes three weeks instead of three quarters, it does not have to.

The product makes the services business better

The two are not just compatible. They feed each other.

AttiBooks is proof. When I tell a prospect that Craftt does AI-native Attio implementations, "AI-native" is a claim. AttiBooks is the evidence behind it. It shows the implementation work is backed by real engineering against the Attio API, not configuration clicks dressed up in a deck. A services business that has also shipped a product is a different kind of credible.

It runs the other way too. Every implementation is a tour of where Attio has gaps. Some of those gaps are one customer's problem. Some of them are a product. The services business is, among other things, a research function for the product business. I get paid to find the ideas.

The one rule

The advice to pick one is not stupid. There is a real failure mode here, and it is doing both halfway: a services business that is slipping because the founder is distracted, and a product that never gets enough attention to be good.

So I hold to one rule. The product only earns its place if it came out of the services work, not instead of it.

I do not chase product ideas from nowhere. I do not stop a client engagement to go build something speculative. AttiBooks qualified because a paying customer needed it first. The next product, if there is one, has to clear the same bar. It has to be a problem the services business kept hitting, with a customer already attached.

That rule keeps the two from competing. The services business sets the agenda. The product is what I do with the best of what the services business teaches me. One feeds the other, in that order, and the order is the whole discipline.

If you run a services business

If you run a services business, you have probably been told to be careful about products. The warning is not wrong. Doing both badly is easy.

But you are also sitting on something a pure product founder would pay for: a constant, paid stream of real customer problems. Most of them are just services work. A few of them are products, and you are the first to know.

You do not have to pick. You have to be honest about which problems are which, and only build the ones a customer found for you first.