You Might Be a Consulting Company With Good Tools

Back to Blog Listing

You Might Be a Consulting Company With Good Tools

Many founders believe they are running a SaaS company when they are running a consulting company with good internal tools. If your team uses the platform to deliver work for clients who never log in, you are the latter, and that changes how you should hire, price, and focus.

Ben HoustonJuly 15, 20264 min read

I'm keeping the industry and product details vague out of respect for the founder. The pattern is the point.

I was talking with a founder running a software company of about ten people and roughly a million dollars in revenue. He described the business as SaaS: a platform, subscription customers, recurring revenue. At first glance that made sense. The more he described how the company actually operated, the less the label fit.

The Pitch#

He walked me through what the company was doing: several loosely related problems, each aimed at a different type of customer, each with its own workflow and its own definition of a finished result. Impressive range, interesting engineering.

Then came the detail that gave it away. The platform was too complex for customers to use directly, so his team used it to build each solution. The clients never logged in. He wasn't running a SaaS company. He was running a consulting company with good tools.

Who Logs In, and Who Does the Work?#

The test is simple: who logs into the product, and who does the work? It has little to do with whether you write software, use AI to help build things, or have a "platform" behind the scenes.

In a SaaS company, the customer logs into your platform and does the work themselves. Salesforce is heavily customizable, but the customer is in there every day tracking leads and running reports. They experience the product directly.

In a consulting company, your team gathers requirements, builds a solution, and delivers a result. The client experiences the outcome, not the tool. Whether you used a proprietary internal platform, a stack of scripts, or raw code doesn't matter to them. They can't tell the difference, and they don't ask you to add features to "the platform," because they don't know or care that a platform exists.

By that test, this founder was running a consulting company. A good one, doing interesting technical work, with strong internal tooling.

Why the Label Matters#

The label determines how you scale, hire, and price:

Scalability. SaaS scales because the same product serves many customers with little extra work per customer. Consulting scales by adding people: project managers and engineers, roughly in line with revenue. That path is harder and lower margin.

Team composition. A SaaS company invests in product, platform engineering, and a marketing and sales motion. A consulting company invests in project managers, requirements gathering, and delivery capacity. Confuse the two and you hire for the wrong business.

Revenue quality. Recurring fees on top of project work aren't SaaS revenue if the customer never uses the platform. You end up with an awkward retainer sold as a subscription: harder to defend, harder to expand.

Focus. Those several products, each with its own customer type and workflow, all ride on one platform, creating a jack-of-all-trades problem. The platform gets too complex for any single customer to self-serve, which is why his team ends up doing the implementation.

So You're a Consulting Company. Now What?#

If you recognize your business in this description, you have two paths forward.

Stay a consulting business, and own it. Consulting businesses can be good businesses. Steady revenue, deep client relationships, interesting work. The trap is running one while telling yourself, your team, and your investors the SaaS story. Once you accept what you are, the playbook gets clearer: hire project managers and delivery people rather than product marketers, price your work as projects and retainers rather than subscriptions, and set growth expectations that match a people-driven business.

Or transition to a true SaaS platform, where the customer uses your tool directly. This is possible, but it almost never means building more. It means building less. Pick the one use case already showing the most traction, often the simplest and most repeatable one, and simplify the product until a customer in that market can operate it without you. That requires declining the adjacent, more exciting-looking opportunities. Serving every vertical at once is what created the jack-of-all-trades platform complexity that made self-serve impossible in the first place; repeatability comes from narrowing, not expanding.

You can always offer consulting on top of the SaaS platform, or better yet, bring in external "implementation consultants" to handle customer-specific customization of it. But keep in mind that the more you insulate the customer from the platform, the more you risk sliding back into the consulting business.

Either path can succeed. What doesn't work is drifting between them, running a consulting business on a SaaS story.