Reluvate started as a consulting firm. We solved AI problems for enterprise clients. Custom work, every time. Over the past two years, we have been building our own products — Juliette for meeting intelligence, our cold outreach platform, our AI accounting system. Running both simultaneously, with a team of five to eight people, is the hardest thing I have done as a founder.
The fundamental tension is this: consulting work pays the bills today. Product work builds the business of tomorrow. But they compete for exactly the same resource — the time and attention of a small team of very capable engineers. Every sprint cycle is a negotiation between client deadlines and product milestones. Client work almost always wins because it has a contract, a deadline, and a relationship on the line. Product work gets pushed to nights and weekends, which is not sustainable.
We tried the obvious solution: dedicate some people to consulting and some to products. It did not work at our scale. With five to eight people, you cannot afford specialists. Everyone needs to flex between client work and product work depending on the week. The context-switching cost is brutal, but the alternative — letting either the consulting or the product side starve — is worse.
What consulting gives us that pure product companies do not have: real problems. Every product feature we have built came from a pain point we observed during consulting work. Juliette's action item tracking came from watching a client's team forget commitments meeting after meeting. Our accounting system's multi-jurisdiction handling came from a corporate services engagement where we saw the complexity firsthand. We are not guessing what the market needs. We are seeing it up close, repeatedly, across multiple clients.
The productization path follows a pattern that we have now repeated three times. Step one: build a custom solution for a consulting client. Step two: notice that the next three clients need something similar. Step three: extract the common functionality into a reusable system. Step four: polish it into something that can be deployed without our team doing custom integration. Each step takes six to twelve months. The total journey from custom solution to deployable product is eighteen to thirty-six months.
Scope creep is the existential threat to this model. Consulting clients want custom everything. They want the product, but with modifications for their specific workflow, their specific reporting format, their specific approval chain. Every customization pulls the product further from a scalable, maintainable codebase. We have learned to say no to customizations that would compromise the product architecture, even when the client is waving a purchase order. This is incredibly hard when you are a small firm and every dollar matters.
The financial model is tricky. Consulting revenue is lumpy — big projects followed by dry spells. Product revenue is recurring but takes years to build to a meaningful level. During the transition, you need consulting revenue to fund product development, but you also need to protect product development time from being consumed by consulting demands. We manage this with a hard rule: no more than 70% of team capacity goes to consulting, ever. The remaining 30% is sacred product time. Some months that 30% feels irresponsible. It is not.
One thing that helps: our consulting clients become our product customers. The corporate services firm we built custom accounting automation for is now using the productized version. They get a better, more maintained system. We get recurring revenue instead of one-time project fees. The alignment is natural — they already trust us, they already know the system, and they have been using a version of it for months.
The team dynamics require careful management. Engineers who enjoy the variety of consulting get bored working on a single product for months. Engineers who love going deep on a product get frustrated by consulting context-switching. I have lost good people to both problems. The solution, imperfect as it is, is to rotate people between consulting and product work on roughly quarterly cycles. This is not efficient, but it keeps people engaged and builds cross-functional knowledge.
The competitive advantage of this model is underappreciated. Pure consulting firms cannot productize because they never invest in reusable technology. Pure product companies cannot consult because they do not understand the messy reality of enterprise deployment. We do both, which means our products are battle-tested in ways that competitors' products are not. Every bug we find in consulting makes the product better. Every product improvement makes the next consulting engagement faster.
If I were starting over, would I do it this way again? Yes, but with one change: I would start the product work earlier. We waited too long to begin extracting reusable components from our consulting work. By the time we started, we had years of custom code that was harder to generalize than it would have been if we had designed for reuse from day one. The lesson: build custom, but always with an eye toward what you will extract later. Even if later is two years away.