TrueWeb has shipped 6 SaaS products. Each one started as a conversation about a problem Nigerian businesses face. Here's the honest account of how we go from that conversation to something live, and what we've learned doing it.
Week 0: Problem definition (not solution definition)
Every product we've built started with the same question: "What expensive problem does this solve for a Nigerian business?"
Not "wouldn't it be cool if..." Not "there's a gap in the market for..." — which is another way of saying "I don't know who would pay for this."
For HarvestAI (AI-powered crop advisory), the problem was specific: smallholder farmers in Nigeria have no affordable access to agronomist advice. Agronomy consultation costs ₦10,000–₦50,000 per session. Most farmers can't afford it. The AI doesn't replace an agronomist — it makes basic advisory accessible at ₦500/month.
The problem definition phase is non-negotiable. We spend 1–2 weeks on it, involving at least 5 conversations with people in the target market. If we can't explain who specifically pays for this and why, we don't build it.
Week 1–2: Architecture decisions
Once we know what we're building, we make the stack decisions before writing code. For each product, we document:
Frontend: Vite + React for standalone apps (HarvestAI, SupportAI, ReplyAI). Next.js 15 for content-heavy sites that need SSR/SSG (TrueWeb main site). This decision affects SEO, hosting, and deployment strategy.
Backend: Node + Express on Render for API servers. Render's free tier handles development; paid plans handle production. We use a monorepo-adjacent structure where client/ and server/ live in the same repository.
Database: Neon Postgres (serverless, scales to zero, Drizzle ORM). The connection string is the only thing that changes between dev and prod — no server to provision.
Auth: NextAuth v5 for Next.js apps. Firebase Auth for Vite/React SPAs where we need Google/GitHub login without the Next.js dependency. Auth decision is made on day 1 — retrofitting auth into a working app is painful.
Payments: Squad by default. We have working webhook handlers, HMAC verification, and Naira pricing logic from previous products. Reusing this across products saves 2–3 days of integration work.
Email: Resend + React Email templates. Once we have our email flows built (signup, receipt, notification, password reset), they're reusable across products with site-specific branding.
Week 3–4: Core feature build
This is the two-week sprint where the product becomes real. Our rule: build the one thing the product has to do extremely well first.
For ReplyAI (AI review reply manager), that was: paste a Google review → get a professional AI reply in under 3 seconds. Everything else — bulk import, analytics, scheduling — came after that core flow worked perfectly.
For SupportAI (AI customer support bot), that was: customer sends a message → bot responds accurately from the knowledge base. Multilingual support, analytics, escalation — all after core worked.
We use Zustand for UI state, TanStack Query for server state, and shadcn/ui for components. This combination lets us move fast without rebuilding common UI patterns from scratch.
Week 5–6: Integration and hardening
The core feature works. Now we wire everything together:
- Payment integration: Squad checkout → webhook → account activation
- Email flows: every significant event sends a transactional email
- Auth flows: Google/GitHub login, session persistence, role-based access
- Error handling: every API endpoint has structured error responses
- Rate limiting: middleware on auth and payment endpoints
- Logging: structured logs to console (picked up by Render/Vercel)
This phase is unsexy but it's where production readiness comes from. A product that works 80% of the time is unusable. Payment failures that don't send confirmation emails destroy trust.
Week 7: Deployment and testing
We deploy to production infrastructure in week 7, not on launch day. This means:
- Environment variables verified in Vercel/Render dashboards
- Custom domain configured with SSL
- Production database different from dev (never test against prod Neon database)
- End-to-end test of payment flow with real card (₦100 test charge)
- Webhook URLs pointing to production, not ngrok tunnels
The most common launch-day disasters we've seen (from our own early mistakes and from clients' stories): payment webhooks pointing at localhost, missing env vars causing auth to silently fail, SSL not provisioned on custom domain.
Launch week
We don't do big launch days. We do quiet launches to 5–10 beta users first. Real usage finds bugs that no amount of internal testing does.
Beta feedback from SupportAI's first week: users wanted to see which questions their bot couldn't answer. We hadn't built an "unanswered questions" dashboard. It became our most-used feature post-launch.
The actual public launch happens after beta feedback is incorporated — usually 1–2 weeks after the quiet launch.
The number that matters: time to first paid customer
Our internal metric is "days from first commit to first paying customer."
| Product | Days | |---|---| | ReplyAI | 34 | | HarvestAI | 41 | | SupportAI | 28 |
These numbers are only possible because we reuse infrastructure (payments, email, auth, components) across products. Product 2 was faster than product 1. Product 3 was faster still.
What we've learned
-
The spec you write on day 1 is wrong. Write it anyway — it forces clarity. But budget 30% of sprint time for "the thing we didn't know we needed to build."
-
Payments are not a feature — they're a system. Treat the payment flow, webhook handler, email receipt, and account activation as one unit. They all need to work together on every charge.
-
Mobile-first is not a guideline in Nigeria — it's survival. Every product we've built has 60–80% mobile users on the first day.
-
Simplicity wins. The products with fewer features used those features more deeply than products with comprehensive feature sets nobody explored.