The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Your SaaS probably doesn't need microservices.
At least not yet.
I've seen early-stage products split into 5, 10, even 12 services before they have enough users to justify that complexity.
Why?
Because "that's how Netflix does it."
But you're not Netflix.
You're trying to build a product, talk to customers, ship features, and get your first users.
The last thing you need is more infrastructure to maintain.
For most early-stage SaaS products, I'd start with a modular monolith.
Something like:
Laravel + Vue 3 + Inertia.js
You get a clean architecture without turning every feature into a separate service.
A few things become much easier:
1. One deployment instead of coordinating multiple services
2. Simple database transactions
3. Easier debugging
4. Less infrastructure to maintain
5. Lower operational overhead
6. Faster feature development
And here's the important part:
Starting with a monolith doesn't mean you're stuck with it forever.
If your video processing suddenly needs its own servers, extract it.
If your analytics workload becomes huge, separate it.
If search needs to scale independently, pull it out.
Make the architecture more complex when the problem actually exists.
Not because you think it might exist someday.
Microservices can absolutely be the right choice.
But for an early-stage SaaS or web apps, I'd rather spend my time building features and talking to users than debugging communication between services that don't need to be separate yet.
Start simple. Build modularly. Scale when you have something worth scaling.
What's your approach?
Monolith first, or microservices from day one?
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
🤔When applying to jobs, I often see requirements like “advanced Figma skills” or “using best practices, Auto Layout, components, variables, etc.”
Come on, this is the basics.🤷🏻♀️
As a designer with 10+ years of experience building SaaS web applications, I see these things as a foundation, not something that should even need to be asked about.
But since clients often want proof of these skills, I decided to write an article showing exactly how I organize a large SaaS web application in Figma.
I think it can be useful not only for clients, but also for experienced designers and teams.
And I’d be glad to hear about any practices you use that I didn’t mention.🙌
PULSE — Project Management SaaS Dashboard
PULSE is a modern Project Management SaaS dashboard designed to help teams manage projects, tasks, deadlines, and collaboration from one workspace.
The interface focuses on clean information architecture, clear hierarchy, structured tables, and efficient team workflows.
Total 6 Screens
• Dashboard
• Projects
• Project Details
• Tasks
• Team
• Calendar
Focus: SaaS UI/UX • Dashboard Design • Project Management • Tables • Team Collaboration • Responsive Web UI
Six screens with a clear structure, nice. Structured tables are where PM tools usually fall apart once real data hits them (long names, 200+ rows, empty states), and your layout leaves room for that. As a developer who builds dashboards like this, I'd love to see how the...
An infant sleep consultant is a freelancer with flexible hours, managing availability for online meetings with new customers and already paying customers is a nightmare. I build a complete SaaS with family management, ongoing programs with daily updates and charts (sleep sense program) and availability management simple, easy and poke yoke.
Imagine you are the consultant, you already managed the availability for next week, now you have to go to the dentist for an urgency, how many clicks do you have to do to manage the personal appointment in order to not affect the customers? You just add the event on your personal Google Calendar and everything fits automatically. For the customer you have 2 types of journeys, studied specifically for each of them,
1. new customer: CTA has to be simple and easy, with emotional hook (we are talking about parents that have kids with sleep disorders), with low friction and few mandatory clicks. New customer receives an email with the google meet link, he's not a paying customer so the no-show can be high, the system sends a new email 24 hours before the meeting with the possibility to change the hour and date, all automatically picking from the already chosen availability from the consultant.
2. families ongoing the program: already paying customers has higher retention so there's no need for the 24 hour mail before meeting, friction reduced and simplification of codebase and mails. They see specifically the availability dedicated to them called "chiamata di supporto", to let the consultant dedicate herself to different types of customers with different availability schedule.
They main goal of the project is not just make a good codebase with lovable, but develop it around the business. Freelancing and specific work life balance needed by the consultant where the 2 drive points that were needed to be taken into account.
Before it was whatsapps, write the number somewhere, messages, send links, save links somewhere, if I have to go to the dentist? how can I change quickly my availability? now it's just automatic.
