The false confidence of a working prototype
Our IP address management platform started as a weekend project. The network team needed something better than spreadsheets, so we built a quick Django app with a PostgreSQL backend. It worked. People used it daily. Three months in, someone suggested turning it into a product.
That conversation marked the beginning of eighteen months of humbling work. The internal tool that felt 80% complete was actually closer to 30% ready for external customers. The gap between 'works for us' and 'works for anyone' proved wider than expected.
Internal tools grow organically around tribal knowledge. Everyone knows that clicking 'Import' twice causes duplicates, so nobody does it. Everyone remembers that subnet calculations fail for /31 links, so they enter those manually. These unwritten rules dissolve the moment you introduce paying customers who expect software to simply work.
Multi-tenancy breaks everything you assumed
The single biggest technical shift was multi-tenancy. Our internal version had one database, one set of users, one permission model. Converting to proper tenant isolation meant re-architecting the data layer, the authentication system, and the entire application context.
We chose a hybrid approach: shared database with tenant ID columns, plus row-level security policies. Every query needed modification. Every API endpoint required tenant validation. We discovered seven places where queries inadvertently crossed tenant boundaries during testing, any one of which would have been catastrophic in production.
Performance became a different beast entirely. Internally, we had 50 users and 12,000 IP addresses. Suddenly we needed to support scenarios with 500 users and 500,000 addresses per tenant, multiplied across dozens of tenants. Indices that worked fine before collapsed. Queries that ran in 200ms took 8 seconds. We rewrote the subnet search algorithm three times before it scaled properly.
When users become strangers
Internal users forgive rough edges. External customers do not. Our original error messages were developer-friendly: 'Constraint violation on subnet_overlaps'. Helpful when you understand the schema. Useless to a network engineer who just wants to add a VLAN.
We spent two months on error handling alone. Every failure mode needed a human-readable message, a suggested fix, and a way to report the issue if it seemed like a bug. We built a proper logging system with correlation IDs so support could trace user actions across microservices. The internal version logged to a file that three people checked occasionally.
Onboarding shifted from a 15-minute screen share to a self-service flow. We needed documentation, video tutorials, an interactive product tour, and a sample dataset that demonstrated features without being condescending. The first external beta tester spent 20 minutes clicking around before asking what the product actually did. Our navigation made perfect sense to us. It made none to strangers.
- Error messages moved from technical codes to plain-language explanations with remediation steps
- Authentication expanded from internal SSO to supporting Google, Microsoft, SAML, and email/password
- Data import changed from 'upload CSV and we'll fix it manually' to validated schemas with clear rejection reasons
- Reporting went from hardcoded queries to a flexible filter system that handled unexpected use cases
The infrastructure tax
Running a SaaS means infrastructure you didn't need internally. We added monitoring, alerting, automated backups, disaster recovery, and a proper CI/CD pipeline. The internal tool deployed when someone ran a bash script. The SaaS product required zero-downtime deployments, canary releases, and automated rollbacks.
Security requirements multiplied. SOC 2 compliance wasn't relevant for an internal tool. For a commercial product, it became mandatory. We implemented audit logging, encryption at rest, secrets management, and penetration testing. The codebase grew by 40% just handling security and compliance requirements.
Costs changed dramatically too. The internal tool ran on a single server that cost $120 monthly. The SaaS version needed redundant infrastructure across regions, a CDN, managed databases, and monitoring services. Monthly infrastructure costs hit $2,400 before we had 10 paying customers. The economics only worked at scale.
Commercial realities beyond code
The technical transformation was matched by commercial challenges. Pricing an internal tool is easy: it costs nothing. Pricing a product meant researching competitors, understanding value metrics, and testing customer willingness to pay. We mispriced initially, offering too much in a low tier and forcing an awkward restructuring six months later.
Support became a full-time function. Internally, someone would walk over to a desk. Externally, we needed a ticketing system, SLAs, and coverage across time zones. The first customer issue that arrived at 2am, marked urgent, taught us about on-call rotations the hard way.
Legal and financial infrastructure appeared from nowhere. Terms of service, privacy policies, data processing agreements, liability insurance, payment processing, tax compliance across jurisdictions. These aren't technical problems, but they consumed weeks of effort and legal fees that would have funded another developer.
What we'd do differently
Looking back, the mistake was underestimating the gap. We should have treated the SaaS version as a new product that borrowed ideas from the internal tool, not as an enhancement project. The codebases eventually diverged so much we maintained them separately.
Starting with multi-tenancy from day one, even for an internal tool, would have saved months of refactoring. Building proper error handling, logging, and observability early would have prevented technical debt that compounded painfully. The internal version's shortcuts became the SaaS version's roadblocks.
YS Infomatics has built both internal tools and commercial SaaS platforms, and the approach differs fundamentally from the start. Internal tools optimise for speed and iteration within known constraints. SaaS products require resilience, scalability, and defensive programming against unknown user behaviour. The technical and commercial bar sits in a different place entirely. Recognising that gap early determines whether the transition succeeds or becomes an expensive lesson in hidden complexity.