Building a portfolio of vertical SaaS platforms simultaneously is not a strategy most software companies pursue. The conventional approach is to identify one market, build one product, and scale it until it reaches its ceiling before considering what comes next. Drakos operates on a different model.
These are not random observations. They are a systematic signal that a market is ready for a purpose-built replacement. Finding those signals, evaluating the opportunity they represent, building the right product, and getting it to operators who need it — that is the Drakos methodology. It is specific, repeatable, and built from firsthand experience in exactly the kinds of industries we now build software for.
Identifying the market
We look for five specific conditions before deciding a market is worth building for. The first is per-unit pricing by the incumbent. Per-unit pricing is a signal that the dominant vendor is extracting value from operator growth rather than earning it. It is also a signal that every growing operator in that market has a compounding reason to switch.
The second condition is software stagnation. When the dominant tool has not shipped a meaningful update in twelve to twenty-four months, the operator base is being served by software that is falling further behind what modern platforms can provide. Legacy vendors under PE ownership typically cut R&D budgets after acquisition, which means the gap between what they offer and what operators need widens every month.
The third condition is operator frustration with specificity. Generic frustration — "we don't love our software" — is not a signal. Specific frustration — "we can't get a mobile-accessible pesticide application report that our state regulator will accept" — is a signal. Specific frustration identifies workflow gaps that the operator cannot work around and that represent genuine competitive surface area for a purpose-built replacement.
The fourth condition is the spreadsheet indicator. If any operator in the market is maintaining a spreadsheet for a workflow that their primary software is supposed to support, the software is failing them. The spreadsheet is a workaround that represents a missing feature, a broken workflow, or a compliance requirement the software does not handle. It is also the clearest possible signal that an operator is not fully on any software platform and is therefore actively vulnerable to a better solution.
The fifth condition is the list availability of the customer base. This is more operational than strategic, but it matters for go-to-market. If verified operator lists for the industry are readily available — licensing databases, trade association directories, business registrations — the direct outreach economics work. If the customer base is diffuse and unlisted, the acquisition cost is structurally higher.
Evaluating before building
Once we identify a market that meets the five conditions, we evaluate the opportunity against a specific set of criteria before committing to a build. Market size and addressable customer count come first — not because small markets are not worth serving, but because they affect the economics of a portfolio approach. Regulatory requirements get examined early because they have the most significant impact on build complexity. A market that requires EPA-formatted compliance records or state-licensed practitioner tracking has more build surface area than a market that does not, and that affects the timeline and resource requirement.
We evaluate the pricing model of the incumbent against a flat rate alternative. If the incumbent is charging $2 per pool per month and a meaningful portion of the operator base has more than 150 pools, there is a clear flat rate threshold at which the economics dramatically favor switching. If the incumbent is already at a low flat rate, the pricing arbitrage is smaller and the product advantage has to carry more weight.
We evaluate the build complexity against our core stack. Simpler, more focused workflows go to market faster and generate real usage data sooner. More complex workflows with deep integration requirements take longer and carry more risk. Both are worth building — but they have different resource allocations and timeline expectations.
The build philosophy
Every Drakos platform is built on the same foundational philosophy: purpose-built, mobile-first, flat rate. We build with Bolt for rapid frontend development and Supabase for infrastructure. This stack lets us move from concept to working prototype in days rather than weeks, and from prototype to production in weeks rather than months. Speed matters not because we value fast over good, but because the feedback loop between shipping and learning is the most important factor in building software that operators actually use.
Purpose-built means we do not build horizontal platforms and narrow them to a vertical. We start from the specific workflows of the specific industry. The data model reflects how that industry works. The mobile interface is designed around the specific physical context of the operator — standing on a job site, driving between stops, running a warehouse in a building with intermittent WiFi. The compliance features are built around the actual regulatory requirements of the actual jurisdiction, not a generalized compliance framework that may or may not map to what the regulator actually wants.
Mobile-first means the mobile experience is not an afterthought. The first design decision on every screen is how it works on a phone, and the desktop experience is built to complement that rather than replace it. Operators in field service and logistics have phones. They do not have laptops in their trucks. The software has to work in the field or it does not work.
The go-to-market philosophy
We do not use paid acquisition in the early stages of a platform launch. We use direct cold email to verified operator lists. The decision is partly economic — paid acquisition at scale requires a customer lifetime value to support it that is not certain until you have real retention data — and partly philosophical. Operators in fragmented markets are acutely attuned to whether someone actually understands their business. A cold email that demonstrates specific knowledge of the industry, the software problems operators face, and the concrete way the product addresses them performs differently than a generic SaaS acquisition email. It communicates credibility before the operator has ever seen the product.
We run sequences, not blasts. A single cold email is rarely enough to convert a busy operator. A sequence of three to four touches over two weeks — each adding something specific and relevant — earns attention that a one-time blast does not. The goal of the sequence is to get the operator to try the product, not to persuade them. The product does the persuading. The email gets them to the door.
What we look for in the first thirty days is not revenue. Revenue follows retention, and retention follows genuine daily usage. What we look for in the first thirty days is operators who log in every single day because the software solves a real problem they have every real day. A single operator who logs in daily and completes their core workflow in the software is more valuable signal than ten operators who logged in twice and went quiet. The daily user is telling you the software works. The operators who went quiet are telling you it does not work well enough yet.
The portfolio approach
Building twenty-four platforms simultaneously is not a distraction or a lack of focus. It is a portfolio strategy that reflects a specific belief about how fragmented markets work and how risk should be managed across a set of bets on those markets.
Some platforms will break out. They will find markets where the operator base is large, the incumbent is weak, the switching friction is low, and the flat rate economics are compelling. These platforms will grow fast and deserve more resource allocation — more product development, more go-to-market investment, more support infrastructure. Some platforms will find their ceiling early. The market may be smaller than estimated. The regulatory requirements may be more complex than anticipated. The incumbent may be more defensible than the initial evaluation suggested. These platforms serve their operator base well, but they do not scale to the same magnitude.
The portfolio approach ensures that no single vertical disappointment is a company-level setback. When twenty-four platforms are in development simultaneously, the ones that break out carry the portfolio while the ones that find their ceiling early provide valuable operational learning that improves the next cohort of launches. This is not how most software companies are built. Most software companies make one bet on one market and live or die with that bet. Drakos makes many bets on many markets, manages them as a portfolio, and allocates resource toward the bets that are working while maintaining the ones that are not yet.
The twenty-four platforms in development today will not all be equal in scale two years from now. But they will all be serving operators who currently have no good option. And the ones that break out will be the foundation of what Drakos becomes at scale — a portfolio of purpose-built vertical platforms that collectively serve a significant portion of the fragmented operator market across the industries that keep the American economy running every day.