A Micro-SaaS business sells access to a narrowly focused software product, usually through a recurring subscription, while remaining operable by one owner and bounded specialist support.
The product solves one repeated problem for a specific customer. It is not simply an unfinished software-as-a-service company waiting to hire a conventional team. Its small scope is part of the design.
This example follows an illustrative product called Approval Lane. It helps small video-production studios collect timestamped client feedback and secure final approval without long email threads. The numbers are hypothetical, internally consistent, and shown to explain the operating model rather than promise income.
What Is a Micro-SaaS Business?
Software as a service, or SaaS, gives customers access to an application hosted on cloud infrastructure. The NIST SaaS definition distinguishes this from software whose underlying servers and operating systems the customer manages.
Micro-SaaS applies that delivery model to a narrow business:
- One identifiable customer segment
- One expensive or frequent workflow problem
- A deliberately limited product surface
- Recurring or usage-based revenue
- One owner who controls product, economics, and priorities
- Automation and contractors used without building a permanent employee hierarchy
The defining feature is not a revenue ceiling or a particular technology. It is the ability of one owner to direct the complete system responsibly. The broader Micro-SaaS model explains where this structure fits among other one-person businesses.
Micro-SaaS Business at a Glance
| Element | Illustrative design |
|---|---|
| Product | Client feedback and approval portal for small video studios |
| Core customer | Studios producing 5–30 client projects per month |
| Primary job | Collect precise feedback and create a documented approval record |
| Starter plan | €39 per month |
| Studio plan | €99 per month |
| Ending customers | 129 |
| Ending monthly recurring revenue | €6,651 |
| Main acquisition channels | Workflow content, partner referrals, and integration directories |
| Founder role | Product decisions, customer research, marketing, and exception handling |
| Specialist support | Security review, legal review, bookkeeping, and bounded development |
| Main risks | Churn, support load, security incidents, platform dependence, and founder concentration |
How the Example Product Works
Approval Lane is not a complete project-management platform. A studio creates a project, uploads or links a review copy, invites the client, receives timestamped comments, records revisions, and requests final approval.
The product replaces a recurring coordination problem rather than a customer’s entire operating system. That boundary reduces development, documentation, onboarding, and support work.
Customer and Problem
The target customer is a small video studio that handles enough concurrent client work for email-based feedback to become unreliable. The buyer can calculate the cost of unclear comments, missed revisions, and disputed approval.
“Anyone who sends files to clients” would be a larger audience but a weaker market definition. Different professions use different file types, approval rules, security expectations, and terminology. Narrow positioning makes the product easier to explain and test.
Minimum Workflow
The first useful workflow contains only six actions:
- Create a client project.
- Add a review asset.
- Invite reviewers through a controlled link.
- Capture timestamped feedback.
- Mark comments resolved.
- Record final client approval.
Billing, authentication, backups, audit records, and account administration are not visible product features, but they are part of the minimum operational system.
What the Product Does Not Do
Approval Lane does not edit video, manage studio finances, schedule production crews, store unlimited source footage, or replace a full client portal. Each exclusion protects the product’s central promise.
A feature request is accepted only when it improves the core approval workflow for a meaningful share of the target customers. One large customer does not automatically get to redefine the roadmap.
Validate the Problem Before Building Software
The most expensive Micro-SaaS mistake is automating a problem that customers do not prioritize. Code can prove that a product works technically; it cannot prove that buyers will adopt or pay for it.
Observe the Existing Workaround
The founder interviews 15 studio owners and asks them to demonstrate the last project in which feedback caused delay or rework. Evidence includes email chains, spreadsheets, messaging threads, version names, and the time spent reconciling them.
The aim is to identify behavior, frequency, consequence, and budget—not collect compliments about an idea. The market research process provides a structured way to investigate those signals.
Deliver the Result Manually
Before building a complete application, the founder runs three paid approval workflows using existing tools and a manual project log. This tests whether studios will invite clients, whether clients participate, which reminders are necessary, and what counts as accepted approval.
A narrow minimum viable offer can validate the outcome while the founder still performs some steps behind the scenes.
Define a Paid Validation Threshold
For this example, the founder will build the first self-service version only after five studios pay for the managed pilot, at least three use it on a second project, and no unresolved legal or security requirement makes the model impractical.
The threshold is deliberately behavioral. Survey interest, wait-list signups, and free trials are useful signals, but repeated paid use is stronger evidence.
Design the Subscription Offer
The offer must connect price to a customer’s recurring use without creating unpredictable obligations for the owner.
Starter Plan: €39 per Month
- Five active projects
- Three internal users
- Client reviewers without paid seats
- Standard file and link review
- Email support with a two-business-day target
Studio Plan: €99 per Month
- Twenty-five active projects
- Ten internal users
- Custom approval wording
- Project templates
- Priority support with a one-business-day target
The higher plan changes capacity and workflow control, not the fundamental result. The founder avoids a bespoke enterprise tier because security questionnaires, custom contracts, integrations, and service commitments could turn a small product into custom software consulting.
Trial and Onboarding
A 14-day trial asks the user to complete one real approval cycle. The activation milestone is not account creation. It is the first client comment followed by a recorded approval.
Onboarding uses a sample project, a short checklist, and event-based messages. If the studio does not invite a reviewer within two days, it receives one focused prompt. Messages stop when the step is complete.
Illustrative Monthly Economics
At the end of the example month, Approval Lane has 102 Starter customers and 27 Studio customers.
| Revenue component | Calculation | Amount |
|---|---|---|
| Starter MRR | 102 × €39 | €3,978 |
| Studio MRR | 27 × €99 | €2,673 |
| Total ending MRR | €3,978 + €2,673 | €6,651 |
| Annualized run rate | €6,651 × 12 | €79,812 |
The annualized figure is not guaranteed annual revenue. It is the ending monthly recurring revenue multiplied by 12, assuming no future churn, contraction, expansion, failed payments, or price changes.
Monthly Cost Structure
| Cost | Illustrative amount |
|---|---|
| Hosting, storage, email, and monitoring | €420 |
| Payment, billing, and transactional costs | €221 |
| Specialist development and security reserve | €850 |
| Software, accounting, insurance, and legal reserve | €600 |
| Marketing cash spend | €1,050 |
| Total operating cash costs | €3,141 |
| Cash result before owner compensation and tax | €3,510 |
Low infrastructure cost does not make revenue equivalent to profit. Product maintenance, security work, customer support, failed payments, taxes, and owner labor remain real costs. The profitability guide shows how to separate business surplus from unpaid founder labor.
Owner Time
| Activity | Hours |
|---|---|
| Product and engineering | 48 |
| Customer support and success | 22 |
| Marketing and sales | 28 |
| Research and analytics | 10 |
| Administration and finance | 10 |
| Total | 118 |
The cash result per owner hour is €3,510 ÷ 118, or €29.75 before owner tax. This is not an hourly price. It is a diagnostic showing whether the model currently compensates the founder adequately for the time and risk involved.
Track Recurring Revenue Movement
Ending MRR alone hides how the customer base changed. The example month starts with 120 customers and €6,021 in MRR.
| Movement | Customers | MRR effect |
|---|---|---|
| New subscriptions | 14 | +€786 |
| Expansions | Existing customers | +€198 |
| Contractions | Existing customers | −€39 |
| Churned subscriptions | 5 | −€315 |
| Net movement | +9 | +€630 |
| Ending position | 129 | €6,651 |
Customer Churn Rate
Monthly customer churn equals customers lost during the month divided by customers at the beginning of the month.
5 ÷ 120 = 4.17%
The denominator excludes new customers because they were not available to churn for the entire measurement period. Segmenting by plan, acquisition channel, and customer age is more useful than relying only on the blended rate.
Gross Revenue Churn
Gross revenue churn measures lost and contracted recurring revenue without counting expansion.
(€315 + €39) ÷ €6,021 = 5.88%
Net Revenue Churn
Net revenue churn subtracts expansion revenue from churned and contracted revenue.
(€315 + €39 − €198) ÷ €6,021 = 2.59%
A positive result means the existing customer base shrank in recurring revenue during the month. The site’s guide to MRR, ARR, and churn explains these recurring-revenue measures in more detail.
Measure Acquisition and Payback
The business acquired 14 new customers during the month. Cash marketing spend was €1,050, and the founder spent 28 acquisition hours. At an internal labor value of €45 per hour, founder acquisition labor was €1,260.
Customer Acquisition Cost
Cash-only customer acquisition cost is:
€1,050 ÷ 14 = €75
Fully loaded acquisition cost is:
(€1,050 + €1,260) ÷ 14 = €165
The fully loaded measure prevents “free” founder labor from making a channel look more efficient than it is.
CAC Payback
The 14 new customers generated €786 in new MRR. If their estimated contribution margin after variable infrastructure, payment, and support cost is 90%, their first-month contribution is €707.40, or €50.53 per new customer.
€165 ÷ €50.53 = 3.27 months
This payback estimate becomes unreliable if early churn is high. Acquisition should be evaluated by cohort so the founder can see whether a channel attracts customers who activate, remain, and expand.
Define the Core Product Metrics
A small software business needs a compact dashboard tied to customer value and operational risk.
| Metric | What it answers | Example definition |
|---|---|---|
| Activation rate | Do new accounts reach initial value? | Trial accounts completing one client approval within 14 days |
| Time to value | How quickly does value appear? | Median time from signup to first recorded approval |
| Weekly active studios | Is the workflow recurring? | Paid accounts with a review or approval event in seven days |
| Support contacts per account | Is service load controlled? | Non-spam support conversations divided by paid accounts |
| Approval completion rate | Does the core workflow finish? | Projects requesting approval that record a decision |
| Customer churn | How many accounts leave? | Lost customers divided by opening customers |
| Net revenue retention | Does the existing base grow or shrink? | Opening MRR minus churn and contraction plus expansion, divided by opening MRR |
Each event needs one documented definition. If a dashboard changes the meaning of “active” or “churned” without restating prior periods, trends become misleading.
Control Support and Maintenance
Micro-SaaS is a continuing service. Even a stable interface requires monitoring, dependency updates, billing recovery, customer communication, and correction of defects.
Separate Support From Product Consulting
Support covers account access, defects, billing, product behavior, and instructions for the standard workflow. It does not include designing a studio’s client process, importing arbitrary historical data, or building custom integrations.
A documented customer support system should define channels, response targets, priorities, escalation, and knowledge-base ownership.
Budget for Maintenance
The monthly specialist reserve is funded whether or not it is fully spent. Unused money remains available for security work, dependency upgrades, emergency fixes, or a bounded technical review.
Maintenance capacity is not the same as feature capacity. Reliability and security work take priority when delay would threaten customers or the business.
Use a Feature Budget
The founder allows no more than one meaningful product change per month unless a defect or security issue requires immediate action. Requests are grouped by the customer job they affect, not counted as votes for isolated interface changes.
Manage Security, Privacy, and Reliability
A one-person owner remains responsible for the product’s risk decisions even when cloud vendors and contractors operate parts of the system.
Collect Less Data
Approval Lane stores review assets, comments, identities, and approval events. It does not collect data unrelated to this workflow. Retention periods, deletion behavior, subprocessors, and export options are documented before sale.
Use Verifiable Security Controls
Authentication, access control, logging, input validation, backups, dependency management, and incident response need explicit owners and tests. The OWASP verification standard provides a structured basis for evaluating web-application security controls.
A contractor can conduct a security review, but the founder must understand the findings, choose remediation priorities, and confirm completion.
Design Recovery Before an Incident
The business keeps encrypted backups, tests restoration, documents critical vendors, exports billing and customer records, and maintains a communication template for service disruption. The data backup strategy should specify recovery priorities rather than merely confirm that backups exist.
Handle Tax and Contract Obligations
Subscription software can create tax, consumer, privacy, and contract obligations in the places where customers are located. The exact rules depend on jurisdiction, customer type, product design, and seller location.
For example, the European Commission explains that the VAT One Stop Shop can let eligible sellers declare covered cross-border consumer supplies through one Member State rather than registering separately in every relevant Member State. That does not remove the need to classify transactions, collect evidence, apply the correct rate, keep records, and file accurately.
The founder gets professional advice before selling across jurisdictions and defines:
- Subscription term and renewal
- Cancellation and refund process
- Acceptable use
- Service availability language
- Data processing roles
- Liability limits where lawful
- Account closure and data export
This section is operational context, not legal or tax advice.
Main Risks in This Example
Churn Masks Acquisition Progress
Adding 14 customers looks encouraging, but losing five in one month is material. If churn persists, more marketing may increase activity without creating a durable revenue base.
One Customer Reshapes the Product
A large account may request custom permissions, contracts, storage, or integrations. The added revenue can be attractive while the hidden support and compliance burden destroys the one-person model.
The Founder Is the Incident Response Plan
If only the founder can diagnose failures, restore data, access vendors, and communicate with customers, illness or unavailability becomes a business-wide outage risk.
Platform and Vendor Dependence
Payment processors, cloud services, authentication providers, email platforms, app directories, and integration partners can change price, policy, or access. Critical data must be exportable, and essential functions need documented alternatives.
Technical Debt Consumes Capacity
Fast early changes can leave fragile code, missing tests, poor observability, and undocumented decisions. The apparent speed is borrowed from future maintenance time.
Who This Model Fits
A Micro-SaaS business can fit a founder who:
- Understands one recurring customer workflow deeply
- Can tolerate delayed returns while the product is validated
- Enjoys product decisions and continuing maintenance
- Can communicate boundaries and decline custom work
- Is willing to own security, privacy, and reliability decisions
- Prefers recurring relationships to repeated project sales
It is a poor fit for someone seeking passive income, avoiding customer support, or expecting code alone to produce distribution.
Common Micro-SaaS Mistakes
Building Before Observing
The founder translates an imagined problem into features without studying an existing paid or costly workaround.
Serving Several Markets at Once
Generic positioning creates incompatible onboarding, terminology, integrations, and feature requests.
Confusing MRR With Profit
Recurring revenue is reported without deducting variable delivery, acquisition, support, maintenance, administration, and owner labor.
Offering Unbounded Support
Fast personal replies become part of the implied offer even though the subscription price cannot fund them.
Measuring Signups Instead of Value
The dashboard celebrates registrations while ignoring activation, completed workflows, retention, and support demand.
Ignoring Exit and Continuity
Infrastructure, credentials, product knowledge, and customer relationships remain understandable only to the founder, making the business difficult to recover, transfer, or sell.
Micro-SaaS Action Checklist
- Define one customer, recurring problem, and observable consequence.
- Study real workflows and existing workarounds.
- Sell a paid manual or low-code pilot before building broadly.
- Set a behavioral validation threshold.
- Write the narrow workflow and explicit exclusions.
- Choose a price metric customers understand and the business can support.
- Define activation, retention, churn, and revenue movement consistently.
- Calculate cash-only and fully loaded acquisition cost.
- Set support boundaries and service targets.
- Budget for security, maintenance, legal, accounting, and recovery.
- Document vendors, credentials, backups, incident steps, and data exports.
- Review customer concentration, founder dependence, and platform risk monthly.
Frequently Asked Questions
Does Micro-SaaS Have to Be Built by One Person?
No. A solopreneur may use contractors, managed infrastructure, and specialist advisers. The owner still directs the business and retains responsibility for product, risk, quality, and economics.
Is Micro-SaaS Passive Income?
No. Delivery can be automated, but the business still requires monitoring, maintenance, customer support, security work, billing administration, research, and marketing.
Should a Micro-SaaS Offer a Free Plan?
Only when the free plan has a defined acquisition or product purpose and its infrastructure and support costs are controlled. A trial is often easier to evaluate because it creates a clear activation window and purchase decision.
What Is the Most Important Micro-SaaS Metric?
No single metric is sufficient. A practical minimum combines activation, recurring use, customer churn, net revenue retention, support demand, contribution margin, acquisition cost, and owner time.
When Should the Founder Add a Feature?
Add it when evidence shows that it improves the core customer outcome, retention, or operational reliability for a meaningful part of the target market. Do not add it solely because one prospect requests it.
Sources and Methodology
This is an illustrative composite, not a profile of a named company. Customer counts, prices, costs, hours, and calculated metrics are hypothetical and are included to make the business mechanics testable.
Definitions and operational cautions were checked against the NIST definition of SaaS, the OWASP Application Security Verification Standard, and European Commission guidance on the VAT One Stop Shop. Legal, tax, privacy, and security requirements vary by jurisdiction and product; qualified advice is necessary for a real implementation.