A SaaS founder I worked with last year had a problem that sounds simple but is not: he had two enterprise prospects ready to pay $50K/year each, but both had the same requirement - their data had to be completely isolated from other customers. Full stop.
His product was built with shared database tables. Tenant isolation was a field called `company_id` on most records. Fast to build, reasonable for early stages - but not what these enterprise buyers needed when they asked about data separation in security reviews.
He had three options: lose the deals, promise something he could not deliver, or spend 4-6 months rebuilding the data layer. None of these options were obvious from inside the problem. He brought me in to help figure out a fourth path.
We found one - a hybrid approach using PostgreSQL schemas that gave these specific customers physical isolation while preserving the existing architecture for everyone else. It took six weeks instead of six months, and he closed both deals.
That moment - where a SaaS-specific technical decision has a direct, measurable dollar value - is exactly what a fractional CTO engagement looks like for a SaaS company.
The Multi-Tenancy Problem Almost Every SaaS Faces
Multi-tenancy is the architectural choice that defines a SaaS product more than almost any other. How you handle tenant isolation determines what customers you can sell to, what your operational costs look like, and how hard certain features are to build.
There are three common models:
The first is shared everything - one database, one schema, `tenant_id` columns everywhere. Cheapest to build, cheapest to run, but limited in the data isolation guarantees you can make. Fine for SMB customers, problematic for enterprise or regulated industries.
The second is schema-per-tenant - still one database, but each tenant gets their own schema. Better isolation, easier to run database migrations per-tenant, moderate operational overhead. This is what PostgreSQL schemas give you, and it is what we used in the case above.
The third is database-per-tenant - maximum isolation, maximum operational cost. Each customer's data is completely separate. This is what some enterprise and regulated customers actually require, especially in healthcare and financial services.
Most SaaS companies start with shared everything and hit the isolation wall somewhere around their first enterprise deal. The question a fractional CTO helps answer: how do you evolve your architecture without stopping feature development for six months?
That question has a specific answer in most cases, and it is usually not as expensive as founders fear once someone has mapped the actual migration path.
Pricing Tiers and the Technical Decisions Behind Them
Pricing tiers in SaaS are a product decision, but they are also an engineering decision, and teams that do not think about them that way end up in trouble.
The classic mistake: a founder decides that the enterprise tier includes "custom integrations" and "dedicated support." The sales team starts promising these things. Nobody has designed what "custom integrations" means technically or how "dedicated support" changes the operations model.
I worked with a B2B SaaS startup where the enterprise tier included "custom reporting." Eighteen months into selling that tier, they had six enterprise customers with six different custom reporting implementations, all maintained by the same two engineers who had to understand every customer's customization to push any schema change. The technical debt was enormous.
The right approach is to design pricing tiers as engineering artifacts from the start. What does each tier actually deliver, technically? What infrastructure costs change? What engineering surface area does each tier create? Which features are gated by configuration vs. which require custom code?
A fractional CTO helps translate product pricing decisions into technical requirements before the company is stuck maintaining something that cannot scale.
API Strategy: Internal First, Then External
Most SaaS companies I work with have never thought of themselves as API companies until a customer asks for an API or a competitor launches one.
API strategy for SaaS has two components that are often confused. Internal APIs are the interfaces between your own services - how the frontend talks to the backend, how background workers access data. External APIs are the product surface you expose to customers, partners, and integrations.
The critical mistake I see repeatedly: building internal and external APIs as the same thing. This seems efficient - one API, two audiences. In practice it means your internal implementation details are now public contracts you cannot change without breaking customer integrations. Versioning gets complicated. Rate limiting, authentication models, and documentation requirements add overhead to engineering changes that should be routine.
The better model: build a clean external API layer that translates your internal implementation into stable public contracts. The internal system can evolve; the external API absorbs the translation.
This matters especially when you start building an integration ecosystem. The Zapier integration, the Salesforce connector, the partner API - these all consume your external API. If that API is well-designed, integrations are fast and partners can build self-service. If it is not, every integration becomes a custom project.
The SaaS-Specific Metrics a CTO Should Be Watching
Technical leadership in SaaS is not just about architecture and team. It is about understanding which engineering metrics connect to business outcomes.
Deployment frequency matters more in SaaS than in most other software contexts, because your customers are using the product every day and competitors are shipping continuously. A team shipping once a month is competitively disadvantaged against one shipping daily, all else equal.
Infrastructure cost per customer is a metric very few early-stage SaaS companies track, but it is the one that determines whether your gross margin is healthy or a problem. I have seen companies at $2M ARR discover that their infrastructure costs were $40 per customer per month in a market where the median gross margin requires it to be under $10. That is not a pricing problem - it is an architecture problem.
API error rates and latency percentiles tell you about the reliability experience your customers are having. Not average latency - the 95th and 99th percentile. The enterprise customer using your system for a critical workflow cares about those edge cases.
A fractional CTO helps you figure out which metrics to track, what good looks like, and what to do when the numbers are wrong.
What a Fractional CTO Engagement Actually Looks Like for a SaaS Company
Most SaaS founders come to me in one of three situations. Either they are pre-product-market-fit and need someone to help make the right architectural bets early. Or they have found PMF and are hitting scaling problems they did not anticipate. Or they are preparing for a raise or an enterprise sales push and need the technical story to be credible.
The engagement looks different in each case, but the core function is the same: executive-level technical judgment applied to the specific decisions that matter right now.
For a SaaS company specifically, that usually means: defining the multi-tenancy model before it becomes a crisis, designing the API strategy before the first partner integration reveals the flaws, and connecting engineering decisions to the business metrics that determine whether the company survives.
I have done this across dozens of SaaS companies in the last 15 years. The problems are remarkably consistent even when the products are different. Tenant isolation hits around the first enterprise deal. Infrastructure costs become a gross margin problem around $500K ARR. API strategy becomes urgent when the first integration partner shows up. None of these are surprises - they are the predictable SaaS milestones that every company hits.
Knowing they are coming and having a plan for them is worth more than reacting after the fact.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr