Most founders chase the wrong things first — funding, fancy offices, perfect code — when the only thing that matters early is finding a real problem and proving someone will pay you to solve it.
You don’t need a Herman Miller chair, a snack bar, or a Series A to build a real tech company. What you need is a problem worth solving, a partner who covers the skills you lack, and the discipline to build only what’s necessary to find out if anyone will pay you. Everything else — the office, the team, the fundraising — comes after you’ve answered that question.
You don’t strictly need one, but the odds are stacked against solo founders in tech for a straightforward reason: the two most critical skills at an early-stage tech company — building the product and selling it — are almost never found in full strength in a single person.
Most people who are excellent coders are not excellent at sales. Most people who are excellent at sales are not excellent at building software. And even if you’re a genuine outlier on both dimensions, you still only have 24 hours in a day. Selling — like coding — is an extremely time-intensive task. Doing both simultaneously at the level required to survive is nearly impossible.
Sweat equity: ownership stake in a startup earned through labor and contribution rather than cash investment. In early-stage tech companies, a technical co-founder who builds the product before the company has revenue to pay salaries is typically compensated through sweat equity — usually structured as a vesting schedule that converts to a formal ownership stake over time as milestones are met. Sweat equity arrangements should always be documented with a formal agreement, not left as a verbal understanding.
The two primary roles to fill at a tech startup are a sales and distribution owner (often called the non-technical founder) and a product and engineering owner (the technical founder). A non-technical founder who believes that building a great product will automatically attract customers is making a dangerous assumption. A technical founder who underestimates how hard it is to sell is making the same one from the other direction.
On equity splits: a 50/50 division sounds fair, but it’s rarely accurate. Different founders bring different levels of risk, time, and expertise. The right split reflects the actual value each person brings to the company at the stage where the company needs it most. Founders who wear many hats in the early days — especially technical founders putting in significant pre-revenue labor — are often undercompensated in default 50/50 arrangements.
Start with a problem you or people you know actually have — not with a product you want to build. This sounds obvious, but most failed startups die because founders fell in love with a solution before they fully understood the problem.
Every product that succeeds exists because it removes friction from something people already need to do. The keyboard solves the problem of getting input into a computer. The switch on the side of your phone solves the problem of your ringtone going off at the wrong time. The specifics don’t matter — what matters is that there is a real, recurring, felt problem that people are currently either solving badly or not solving at all.
The practical way to find this: look at where you or people around you are using workarounds. Spreadsheets where software should exist. Manual processes where automation would save hours. Aggregation tasks where everything lives in siloed systems that don’t talk to each other. These are the seams where product opportunities live.
Once you’ve identified a candidate problem, test your understanding of it by trying to describe it precisely without referencing any solution. If you can articulate the problem clearly — who has it, how often, what it costs them — the product development process becomes much easier, because the problem itself tells you what features you need to build.
The solution to a well-defined problem is your value proposition. This step is largely automatic when you’ve started from the problem rather than the product — your solution should be a direct answer to the frictions you identified.
At this stage, your job is to describe specifically how technology solves the problem, and which features are required to deliver that solution. “Required” is the operative word. Features that would be nice to have are not the same as features without which the core problem is not solved.
Product-market fit — the condition where your solution actually meets the needs of an identifiable market — is also easiest to establish at this stage if you started from a real problem. You’re not guessing whether there’s a market; you’re describing a solution to a pain point you’ve observed in people who are your potential customers.
The harder question is whether the market is large enough and the willingness to pay is strong enough to support a viable business. That’s what the next step — market research — is designed to answer.
Before writing a single line of code, you need to understand the competitive landscape. If no one is solving the problem you’ve identified, that can mean you’ve found a genuine gap — or it can mean others have already tried and found there wasn’t enough demand to sustain a business. Either case is worth investigating.
If there is competition, your decision isn’t whether to walk away — it’s whether you can compete and how. There are three primary competitive strategies in tech:
| Strategy | How it works | Best when |
|---|---|---|
| Cost | Deliver a comparable product at a lower price while remaining profitable — possible through remote operations, efficient engineering, or lower overhead | Established market with price-sensitive buyers and inefficient incumbents |
| Differentiation | Offer something competitors don’t — specific features, a better UX, deeper integrations, or a workflow advantage that materially changes outcomes | Market exists but incumbents have left meaningful gaps in capability or experience |
| Focus | Serve a specific subset of the market that broader competitors ignore — go deep on their unique needs rather than wide across all users | Large general market with an underserved niche that has specific enough needs to justify a tailored product |
Choosing a strategy before you build shapes every product decision that follows. A cost-focused company makes different build-versus-buy tradeoffs than a differentiation-focused one. A focus-based startup needs a much narrower feature set, but it needs to go much deeper on the specific workflows of its target segment.
An MVP — minimum viable product — is the most basic version of your product that still solves the core problem. Not a rough prototype. Not a demo. An actual working product that delivers the value you’re promising, stripped of everything that isn’t essential to proving whether users will adopt and pay for it.
The goal of an MVP is to find out as quickly and cheaply as possible whether you have something. You want to fail fast. A product that fails at the MVP stage wastes less money than one that fails after 18 months of full-scale development.
To scope your MVP correctly, start from your problem definition and list only the features without which the core problem is not solved. Everything else goes on a “later” list. Resist the temptation to add features that would be nice to have, that you personally want, or that competitors have. The MVP is not the finished product — it’s a test.
Scope decisions also apply to platform. If 90% of your target users primarily interact with mobile apps, building a web app first is a misallocation of your limited resources. Build where your users are, for the workflow they already have, and expand later.
Fraction generates full project plans with story-point pricing, sprint estimates, and tech stack recommendations — so you know what you’re getting into before you commit.
Scope Your Project for FreeFree and instant. No calls, no waiting.
Once you know what you want to build and have a rough feature set, you need to answer the technical questions: What APIs, databases, and infrastructure will the product require? How hard is each feature to build? What’s the realistic cost and timeline? Are there technical constraints that should change your feature priorities?
If you’re a non-technical founder, you need someone with a technical background to answer these questions before you start spending money on development. This can be a technical co-founder, an advisor, or a hired developer — but skipping this step leads to expensive surprises mid-build.
For most early-stage startups, fractional technical help is the right model at this stage. A fractional developer or fractional CTO can scope the build, make architecture decisions, and execute the MVP without the carrying cost of a full-time senior hire before you have revenue. This matters most before you’ve hit MVR — committing to a full-time technical salary before the business is self-sustaining is one of the fastest ways to run out of runway. The compensation structure you establish for early technical hires has lasting implications for your cost base as the company scales.
Your business model decision also belongs in this stage. Are you charging a subscription? A one-time fee? Are you free with an ad-supported model? The decision affects your tech architecture (subscription billing requires different infrastructure than one-time transactions), your sales motion, and your financial projections. It also affects how potential acquirers or investors will eventually value the company.
Launch is not a moment — it’s a process. Tell everyone you know. Use every channel available to get the product in front of the people most likely to benefit from it. Then listen. The feedback you collect in the first weeks after launch is more valuable than almost anything you’ll build next.
The critical distinction in listening to feedback: you’re not trying to collect feature requests. You’re trying to understand whether the product is meeting its core promise. If users consistently say it’s close but doesn’t quite do the thing they need, that’s signal worth acting on. If they’re asking for features that would be nice but don’t change whether the core problem is solved, that’s noise.
If you’re hearing consistently that the product is missing the mark — not just from a few users, but from most — you need to decide whether to pivot or stop. Pivoting means changing something fundamental about the product, the market, or both. Stopping means acknowledging that this particular bet didn’t pay off. Both are legitimate outcomes. The mistake is continuing to invest in a product that the market has already told you isn’t working.
If the product is working — people are adopting it, using it repeatedly, and willing to pay for it — the next question is whether you can keep the lights on. That’s where minimum viable revenue comes in. The metrics investors use to evaluate growth-stage companies matter far less at this stage than the single number that tells you whether your business is viable.
Minimum viable revenue (MVR) is the level at which your company breaks even after all operating expenses — including enough salary for you and any co-founders to sustain your lifestyle long-term. It’s not profitability in the investor-pitch sense. It’s the point where you stop burning personal savings and the business covers its own costs.
MVR calculation is straightforward: add your product infrastructure costs, any tooling or service costs, and your and your co-founders’ minimum sustainable salaries. That total, divided by your price point, tells you how many customers you need to reach MVR.
Why does this matter? Because MVR is the first real validation that you have a business, not just a product. A product people use but won’t pay for is a hobby. A product that generates enough revenue to sustain the founders who built it is a company. The gap between those two things is where most startups die.
Once you’re at MVR, your options expand. You can reinvest additional profits to build new features and grow. You can take more income personally. You can choose whether to raise capital from a position of strength rather than desperation. None of those decisions are available to a company that hasn’t answered the fundamental question of whether people will pay for what it’s built.
After MVR: grow deliberately. Hire fractional before full-time. Use your pricing as a lever — lower prices drive volume, higher prices drive revenue per customer. Insource opportunistically when team members have skills adjacent to your needs. And set a clear timeline for major milestones — a go/no-go date for hitting MVR focuses effort in ways that open-ended timelines don’t.
No. Many successful tech companies were bootstrapped without venture capital. Outside funding can accelerate growth but it isn’t required to get started. Focus on reaching minimum viable revenue — the point where the business covers its costs and founder salaries — before considering whether outside capital makes sense for your goals.
Not strictly, but most successful tech startups have at least two founders covering complementary skills: one focused on sales and distribution, one focused on building the product. If you genuinely have both skill sets and the bandwidth to execute them simultaneously, you can go solo — but most people find the dual workload unsustainable over time.
An MVP is the most basic version of your product that still solves the core problem. It omits non-essential features so you can test your idea quickly and cheaply. The goal of an MVP is to validate whether real users will pay for your solution before you invest heavily in building the full product. Failing fast on an MVP costs far less than failing after a year of full-scale development.
Product-market fit exists when your solution directly addresses a clearly defined problem that a specific market already experiences. The clearest signal is that customers are paying for your product without excessive hand-holding and returning to it without being prompted. Starting your product definition from a real problem — rather than a feature you want to build — is the most reliable path to product-market fit.
Hire a developer once you have a clearly defined problem, a rough feature set for your MVP, and some validation that people want the solution. Before committing to a full-time hire, consider working with a fractional developer who can scope the build, answer technical questions, and deliver the MVP at a fraction of the full-time cost — particularly useful before you have revenue to sustain a permanent salary.
Minimum viable revenue is the revenue level at which your company breaks even after all operating expenses — including enough salary for you and any co-founders to sustain your lifestyle long-term. It’s the threshold that separates a viable business from one that’s burning personal savings. Calculate it by adding your product costs, overhead, and combined founder salaries, then work backwards to determine the pricing and customer count required to hit that number.
Praveen Ghanta is a five-time founder and serial entrepreneur. He is the founder of DevHawk.ai, an AI-powered engineering management platform, and Fraction.work, which connects fast-growing companies with top fractional tech and growth marketing talent. Previously, he founded HiddenLevers, a risk analytics platform for wealth management that he bootstrapped from inception to acquisition by Orion Advisor Solutions in 2021, serving thousands of advisors and $600B in assets. He earlier founded SmartWorkGroups, acquired by Intralinks in 2000.
Connect on LinkedIn →Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Scope Your Project for FreeWorking on a data strategy? Talk to a Fraction CTO. → Book an intro call
