How I identified a market gap and built an affordable SaaS solution for businesses who outgrew spreadsheets but couldn't justify enterprise costs.
THE CHALLENGE
Small businesses with 1-15 employees face a painful gap: enterprise inventory systems cost $50-200/month and require weeks of onboarding, while free tools lack critical features like multi-user access and financial tracking.
Target users: Businesses managing 50-500 SKUs who outgrew spreadsheets but can't justify enterprise software costs.
VALIDATED PAIN POINTS
MARKET ANALYSIS
| Solution | The Gap |
|---|---|
| Spreadsheets | No real-time updates, no role-based access, manual reconciliation |
| Enterprise Systems | $500+/month, 6-month implementation, requires IT staff |
| Mid-Market SaaS | $100-300/month, complex onboarding, over-engineered |
| Free Tools | Single-user, no inventory management, limited reporting |
DISCOVERY & VALIDATION
Rather than building first and hoping for adoption, I started with systematic problem validation through structured interviews across retail, food service, and distribution sectors.
Semi-structured interviews across retail, food service, and distribution:
Audited 8 competing products evaluating time-to-value, feature complexity, pricing, and mobile capabilities.
Shadowed 2 business owners during actual workdays to understand contextâwhen they checked inventory, what triggered stock decisions, how sales were recorded.
| Finding | Product Implication |
|---|---|
| Owners check sales/profit daily on mobile | Dashboard must show key metrics immediately on any device |
| Staff turnover is high | UI must be learnable in <30 minutes |
| Internet reliability varies | Need offline capability alongside cloud |
| Trust is earned, not assumed | Full-featured trial required; no "contact sales" friction |
| Barcode scanning expected but poorly implemented | Invest in barcode UX, not just checkbox feature |
PRIORITIZATION & SCOPE
I evaluated every potential feature against two criteria: Does it solve a validated pain point? and Can I build and maintain it as a solo developer?
High complexity, not mentioned as deal-breaker in early research. Deferred to post-launch.
Different market segment; would dilute focus.
Premature optimization. Single-location covers 80% of target market.
Trade-off: Building iOS/Android would triple development scope.
Choice: Invested in responsive web design that works well on mobile browsers.
Rationale: Time-to-market and validation speed matter more than perfect mobile UX for MVP. Can build native apps after proving the concept.
Trade-off: Users wanted both cloud convenience AND offline reliability. Real-time sync would be extremely complex.
Choice: Built separate cloud and desktop versions sharing 90% of codebase, with different pricing models.
Rationale: Captures both market segments without sync complexity. Cloud = $14.99/mo, Desktop = $149 one-time.
Trade-off: Sexy feature, but small businesses with <500 SKUs don't have enough data for meaningful predictions.
Choice: Implemented simpler AI assistant for natural language queries instead.
Rationale: Build for validated current needs, not hypothetical future use cases.
EXECUTION & ITERATION
I structured development in phases, validating assumptions at each stage:
Core data models and basic CRUD operations
Dashboard, sales flow, and inventory management
Multi-user, permissions, audit trails
Reporting, visualizations, AI assistant, desktop version
Showed clickable mockups to 3 business owners. Discovered they wanted profit margin per product, not just totals. Adjusted dashboard design.
Deployed to 2 friendly businesses for real-world use. Key learnings:
Expanded to 8 users. Tracked time from signup to first sale (target: <15 minutes), feature adoption rates, and support request patterns.
| User Feedback | Response |
|---|---|
| "I can't find old sales" | Added search/filter to sales history, receipt number lookup |
| "Low stock alerts are annoying" | Made reorder points optional per product, added bulk edit |
| "Need to track returns separately" | Built dedicated returns/damaged goods module |
| "Dashboard is too busy" | Created customizable dashboard with user-selected widgets |
Problem: Users had years of data in Excel. Manual entry was a non-starter.
Solution: Built CSV import with intelligent column mapping, data validation, preview mode, and error highlighting. This became a key differentiatorâcompetitors charge extra for "migration services."
Problem: Early users requested increasingly granular permissions ("can view sales but not edit," "can see own sales only," etc.).
Solution: Implemented ~15 distinct permissions covering 95% of use cases. Resisted per-record permissionsâthe complexity wasn't worth it for the target market.
OUTCOMES & IMPACT
Live in production at bmsgo.online with:
Average time-to-first-sale
(Target: <15 min)
Dashboard & sales usage
Weekly for reports
Demo-to-trial conversion
vs direct signups
KEY TAKEAWAYS
Building as solo developer with zero budget forced ruthless prioritization. Every feature had to justify its complexity cost. This produced a more focused product than unlimited resources would have.
Shipping a complete solution with rough edges is more valuable than a polished partial solution. Users can work around UI imperfections; they can't work around missing features.
Early conversations shaped every subsequent decision. The 12 initial interviews saved weeks of building wrong things.
The dual pricing model (subscription vs one-time) isn't just business strategyâit fundamentally shapes user expectations and product requirements.
Added usage tracking late. Earlier instrumentation would have informed prioritization better.
I reconstructed rationale for this case study from memory. A contemporaneous decision log would be more accurate.
As solo developer, I could always "add one more feature." Explicit milestones would have prevented scope creep.
The product is learnable but not self-teaching. A guided first-run experience would improve time-to-value.