"This technical deep dive shares the real lessons from building AxiomFlow, CuratoAI, and other platforms serving 50K+ users. We cover tech stack decisions, architecture patterns that enabled scale, mistakes we made, and practical advice for founders building their first product."
Software Specialists @ Accepire
Our engineering team consists of senior developers, cloud architects, and AI specialists with expertise in React, Node.js, Go, Rust, and cloud platforms (AWS, Azure, GCP). We collectively bring 50+ years of experience building scalable software systems.
When we started Accepire in 2024, we faced a common startup challenge: ambitious product goals with limited resources. We needed to build multiple products (AxiomFlow for ESG compliance, CuratoAI for content generation, AutoInvoice.AI, and more) while maintaining the engineering quality we promised clients.
This constraint forced discipline. We couldn't afford to rebuild infrastructure for each product. We needed patterns that scaled across projects and a tech stack that maximized developer velocity without sacrificing reliability.
Two years later, our platforms serve over 50,000 users with 99.97% uptime. Here's what we learned.
Why: JavaScript everywhere means one language across frontend and backend, easier hiring, and shared code (validation schemas, types). TypeScript adds the safety net we need for production systems.
The tradeoff: Node isn't the fastest runtime. For CPU-intensive work, we offload to Go microservices. But for 90% of web application logic, Node's ecosystem and developer productivity win.
Why: Postgres handles 95% of use cases well. JSONB for flexible schemas, excellent full-text search, strong consistency, and the best ecosystem of extensions. We use Supabase for managed hosting with real-time subscriptions built in.
The tradeoff: For truly high-scale time-series data (IoT sensors in AxiomFlow), we added TimescaleDB. For caching and sessions, Redis. But Postgres is the source of truth.
Why: Next.js gives us the best of both worlds—static generation for marketing pages (SEO), server-side rendering for dynamic content (performance), and client-side React for interactivity. Edge deployment via Vercel means global performance without managing CDN configuration.
Why: Vercel for frontend (zero-config deployments, edge functions, preview environments). AWS for backend services (Lambda, RDS, S3, SQS). This split lets us move fast on UI while maintaining control over data and business logic.
Every table includes a tenant_id column. PostgreSQL Row-Level Security policies ensure queries only return data for the authenticated tenant. This is enforced at the database level, not application code—so bugs can't leak data between customers.
-- Every query automatically filtered by tenant
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.tenant_id')::uuid);
Heavy processing (PDF generation, AI inference, data aggregation) happens asynchronously via queues. The user action triggers an event, returns immediately, and a background worker processes the job. This keeps the UI snappy and allows horizontal scaling of workers independently.
REST for simple CRUD and external integrations (predictable, cacheable). GraphQL for complex dashboard queries where the frontend needs flexibility. This hybrid avoids the over-fetching of pure REST and the complexity overhead of pure GraphQL.
Every new feature ships behind a flag. This enables gradual rollouts, easy rollbacks, and A/B testing without deploying new code. We use a simple in-house system backed by Redis—nothing fancy, but essential.
What we did: Started with separate services for auth, notifications, and billing because "that's how you scale."
The problem: Coordination overhead killed velocity. Debugging across services was painful. We had distributed system problems without distributed system scale.
The fix: Consolidated into a modular monolith. Clear module boundaries, but one deployable unit. We'll split when we actually need to—which is probably never for our scale.
What we did: Launched with basic error tracking and called it "monitoring."
The problem: When users reported "it's slow," we had no visibility into why. No distributed tracing, no performance baselines, no alerting on anomalies.
The fix: Implemented comprehensive observability: structured logging, request tracing, performance metrics, and anomaly detection. Now we often know about issues before users do.
What we did: Naive GraphQL resolvers that fetched related data one record at a time.
The problem: A dashboard query that should take 50ms was taking 3 seconds. Database was getting hammered.
The fix: DataLoader pattern for batching and caching within a request. Query performance improved 10x.
What we did: Assumed our error handling worked because the code looked right.
The problem: First time a third-party API went down, our "graceful degradation" turned out to be not so graceful.
The fix: Regular failure injection in staging. We break things on purpose to verify the system handles it correctly.
Our AWS bill for platforms serving 50K+ users is under $3,000/month. Here's how:
We started with the smallest instance sizes and scaled up based on actual metrics. Most startups over-provision by 50%+ out of fear. Monitor first, scale second.
Database and baseline compute run on reserved instances (40% savings). Burst capacity uses on-demand. This hybrid captures most of the savings without lock-in risk.
Edge caching for static assets, Redis for application data, query result caching for expensive computations. Every cache hit is a database query avoided.
Background jobs run on Lambda. We pay only for execution time, and scaling is automatic. Perfect for workloads that spike (report generation, bulk imports) but don't need always-on infrastructure.
Building software at scale is less about brilliant architecture and more about consistent execution of fundamentals. Get the basics right, measure everything, and improve iteratively.
Skip the learning curve. Work with engineers who've already solved these problems. Book a free technical consultation to discuss your architecture.