There is this idea floating around that building a SaaS product takes months. Maybe even a year. You need a team, a runway, a pitch deck, and a whole lot of coffee.
I am here to tell you that is not always true.
I built Landager, a property management platform for independent landlords, and took it from zero to a working MVP in about two weeks. I did this while working a full-time job. Evenings. Weekends. No team. Just me, my laptop, Antigravity(Obviously!) and a clear picture of what I wanted to build.
This is not a humble brag. This is a breakdown of exactly how I did it, what stack I used, how I structured the project, and what decisions saved me the most time. If you are a developer sitting on an idea, maybe this will push you to just start.
The Problem I Wanted to Solve
I did my research using Gemini CLI, I gave it a custom built MCP that focuses on finding pain points beings discussed in various platforms like Reddit. I had got a few Ideas, but the ones that I could simply built and test by myself without much stress were scarce. This is what I choose.
Landlords who manage somewhere between 5 and 15 rental units have almost no good tools. The big property management platforms are built for companies managing hundreds of units. They are bloated, confusing, and expensive. We are talking $35 to $60 per month, often with per-unit fees on top.
So what do most independent landlords actually use? Spreadsheets. Google Sheets. Notebooks. Some of them literally track rent payments with pen and paper in 2026. (Yep, I literally saw the comment on a YouTube review video). The entire research took me about 6 hours max I think. Finding the right Idea was the difficult job, once I had it, it was about making sure the market is there and a well balanced product could provide value!
There is a clear gap here. These landlords need something simple, organized, and affordable. Not enterprise software stripped down. Something built for them from the start.
That was the idea. One clean dashboard where a landlord can manage properties, tenants, leases, rent, maintenance, expenses, and documents. No clutter. No learning curve. No $50/month bill.
Choosing the Tech Stack
This is where a lot of developers overthink things and lose weeks before writing a single line of real code. I did the opposite. I picked tools I already knew well and that I knew would let me move fast.
Here is what I went with(post discussion with Claude!):
Next.js 16 with the App Router. This was the single biggest time saver. With Next.js, I did not need to build a separate backend. API routes live right inside the same project. One codebase handles both the frontend and the backend. No setting up Express. No managing CORS. No deploying two separate services. Just one project that does everything.
React 19 with TypeScript. React because it is what I know best. TypeScript because when you are building fast, type safety catches bugs before they happen. It sounds slower at the start, but it saves you hours of debugging later.
Tailwind CSS 4. I did not want to spend a single minute debating CSS class names or writing custom stylesheets from scratch. Tailwind let me build a clean, modern UI extremely fast. The design looks premium, which matters when you want people to take your product seriously.
PostgreSQL with Drizzle ORM.(This was purely my choice, I’ll tell you why later in the post). It is reliable, well documented, and handles relational data beautifully. For the ORM, I went with Drizzle instead of Prisma. Drizzle is lighter, feels closer to writing actual SQL, and gives you full type safety with your schema. The developer experience is excellent.
NextAuth v5. For authentication, I used NextAuth. It handles email/password login and Google OAuth out of the box. Setting up auth from scratch is one of those things that can eat an entire weekend. NextAuth gave me a production-ready auth system in a few hours.
The key principle here: I did not try anything new. Every tool in this stack was something I had used before. When you are building fast, novelty is the enemy.
The Architecture: Two Apps, One Product
Landager is actually two separate Next.js applications:
The marketing site at landager.com. This is the public-facing website with the landing page, features, pricing, documentation, and blog. It is mostly static content, optimized for SEO and fast loading.
The dashboard at dashboard.landager.com. This is where logged-in users manage their properties, tenants, and everything else. It is fully dynamic, data-heavy, and sits behind authentication.
Why two separate apps instead of one big monolith? A few reasons.
First, the marketing site needs to be fast and SEO-friendly. It uses static generation and server-side rendering for content pages. The dashboard is a completely different beast. It is an authenticated app that talks to the database on every page load. Mixing these two concerns into one app creates unnecessary complexity.
Second, they deploy independently. I can push a copy change to the marketing site without touching the dashboard. I can update a dashboard feature without rebuilding the entire marketing site. This separation keeps things clean.
Third, they can evolve at different speeds. The marketing site changes when I update copy or add a new page. The dashboard changes when I add features. Different cadences, different priorities.
Both apps run on the same VPS, which I will get to in the deployment section.
The Database Design
This is the part I spent the most time on before writing any code. And it was the best time investment I made during the entire build.
I sat down with claude and mapped out every table I would need. Not just for the MVP, but for the features I knew I would want eventually. The schema did not need to be perfect, but the core relationships needed to be right. I know Claude could do this in one sitting, But I kinda needed to know how it was being built.
Handling DB is sometimes headache, but sitting down and trying to find a relation between tables in the huge MYSQL DB’s gave me a satisfaction unparalleled. This is one of the things that I love about my current job, I deal with hospital and National DB’s which was like started 15+ years ago. The difference between the solution you’d need might simply be an = , but there you are in the maze, completely lost! I wanted this feel for this app. That’s just it. Nothing else to say there. IYKYK!
Having a clear picture of how data is flowing through the software has helped me immensely throughout. When I needed to add a feature or remove one, instead of a vague prompt I was able to give specific instructions on what needs to happen, then I would ask the agent for its opinion on the method I suggested. It would say something and suddenly, something even better comes to my mind while reading the reply. This was basically what was happening every step of the way. Just having a conversation with the agent really helped us both to build something beautiful.
I am not gonna bore you with how the DB is designed and also just because…
The key thing with the DB is that everything is relational. A property like an apartment or house, has units. Units have tenants. Tenants have leases. Leases have payments. This means I can query any direction. Show me all payments for a property. Show me all maintenance requests for a tenant. Show me all expenses for this month across all properties.
Drizzle ORM made defining this schema in TypeScript straightforward. And drizzle-kit handled migrations so I never had to write raw ALTER TABLE statements and also never had to run migration commands(later on this note).
Getting the schema right on day one meant I almost never had to go back and restructure tables during the build. That alone probably saved me three or four days.
The 10-Day Timeline
Alright, let me walk you through what actually happened. This is straight from the git history, no fluff.
Day 1 (March 9): The Marketing Site Begins
I started with the marketing site, not the dashboard. This might sound backwards but hear me out. I needed to think through the product properly before building it, and designing the landing page forced me to articulate what Landager actually does. What are the features? Who is it for? What does the pricing look like? Writing the marketing copy was basically writing the product spec.
By the end of day one I had the base model up. Not tested, not pretty, but the structure was there.
Day 2 (March 10): Theme, Docs, and 33 Languages
This was a massive day. I applied the gold and dark theme that gives Landager its premium feel. Got the base working model functional. Added the first version of documentation pages. And here is the wild part: I added 33 language translations for the entire marketing site on day two. This is where Antigravity really earned its keep. Manually translating thousands of strings into 33 languages would have taken weeks. With the right tooling and automated translation scripts, it was done in hours.
Day 3 (March 11): Pricing and Payments
Built out the 3-tier pricing structure (Starter free, Essentials Plus $10/month, Premium $29/month). Got translations updated. By end of day, the marketing site was essentially ready for production. Three days in.
Day 4 (March 12): SEO, Auth, and Exports
This was a grind day. Added SEO meta tags, legal pages (privacy policy, terms, cookie policy). Fixed translations across all locales. Built PDF and Excel export functionality. Set up Google OAuth and email authentication properly. Multiple bug fixes throughout. Six commits that day. It was one of those “I’m in the zone” evenings.
Day 5 (March 13): The Dashboard Takes Shape
This is where the dashboard features started coming together fast. Properties display, units display, upgrade page, onboarding experience, activity logs. I also wrote and translated all the documentation pages into English first, then pushed translations across all 33 languages. The homepage got its final design. Eleven commits. Easily the busiest day of the whole build.
Day 6 (March 14): UX and Performance
Improved the overall UX across the dashboard. SEO updates. Design polish. Optimized for maximum PageSpeed Insights scores. Updated plan naming and translations. Fixed a 14KB bundle issue. The kind of day where you are not building new things but making everything you already built actually good.
Day 7 (March 15): Payments Go Live and Admin Panel
LemonSqueezy payment integration went live. Email templates for subscription events were set up. Free trial flow was finalized. And I started the admin dashboard as a third separate app. Basic admin functionality was completed the same day. The product could now actually accept money.
Day 8 (March 16): The Big Split
This was the day I separated the dashboard into its own repository. It had been living inside the marketing site codebase up to this point, but it was getting too big and the concerns were too different. I created the dashboard-landager repo, copied over all the dashboard code, perfected the routes, fixed the translation keys, and got it running independently. Tenant screening was also added. By end of day, both apps were running separately on the same VPS.
Day 9–10 (March 17–18): Final Polish
Updated all translations across both apps. Fixed the report translation system. Removed unnecessary emojis from the UI. Added custom email language support so users get emails in their preferred language. Updated layout and design for the final touches.
And that was it. Ten days. The product was live, accepting users, processing payments, and working in 33 languages.
Even though its live, I have few more things I am planning to add, not additional features, just extra’s and small changes that would immensely get the app addictive. I will keep doing that, I wanted to go live because the base version was completely setup and payment gateway Imtegrated. It will take some time for all the SEO and other things to really kick in, Even though if you search landager in google, you might see the website, but that’s not the right keyword. I’d give it about a 2 months to see some real traffic to kick in. I thought why waste time. That’s all.
Deployment: VPS Over Managed Platforms
Why a VPS instead of Vercel, Railway, or one of the other managed platforms?
The short answer: cost and control and then I wanted to do just do something on my own server. It’s fun. It really is. Setting up a Next.js with Supabase is definitly easier, but let’s face it, It’s no fun. Doing things like managing my own server, interacting in this world in a “low level” is what made me fell in love with all these. I needed to remember that again. And yes it did work!
Managed platforms are fantastic for getting something live quickly. But they charge per-service and the costs add up fast. A Vercel Pro plan, a managed database, an S3-compatible storage service, and email delivery could easily run $50 to $100 per month for a product that is not even making money yet.
With a VPS, I pay one flat monthly fee for a server. PostgreSQL runs on the same machine. Both Next.js apps run on the same machine. Nginx sits in front as a reverse proxy, routing traffic to the right app based on the domain. SSL certificates come from Let’s Encrypt, completely free.
The tradeoff is more setup work upfront. I had to configure Nginx, set up the Node processes, handle SSL, and write some basic deployment scripts. That took most of day twelve. But once it was done, it was done. Now I push code to Git, pull it on the server, rebuild, and restart. Simple.
The monthly cost of running the entire Landager infrastructure is around $12.99, a fraction of what it would cost on managed platforms. For a bootstrapped product, that matters.
There is another benefit that people do not talk about enough: when something goes wrong, I know exactly where to look. There is no black box. No “the platform had an incident.” I can SSH into my server, check the logs, and fix the problem. That level of control is worth the initial setup time.
What Made 10 Days Possible
Looking back, a few things made this timeline realistic instead of delusional. And I want to be honest about this because I think people either overstate or understate the role of each factor.
Antigravity. Let me just say it. This would not have been a 10-day build without it. I am not saying it wrote the product for me. That is not how it works. But the back and forth between me and the agent was something else. I would describe what I wanted. It would suggest an approach. I would push back or refine. It would execute. The translation files across 33 languages? Antigravity. The seed scripts? Antigravity. The repetitive CRUD patterns across properties, units, tenants, leases? I designed the first one, and Antigravity helped me replicate the pattern across the rest. It is pair programming, but your partner never gets tired, never forgets where a function lives, and never needs to “just check the docs real quick.”
Next.js API routes eliminated an entire layer of work. Not having to build and deploy a separate backend saved at least three or four days. Every API endpoint lives in the same project as the frontend. Same types, same imports, same deployment. One project. That is it.
Drizzle ORM made database work enjoyable. I already talked about why I chose it over Prisma, but I want to emphasize how much it contributed to the speed. Defining schemas in TypeScript, getting full autocomplete on queries, and having migrations handled automatically removed so much friction. I never had to context-switch between SQL files and application code. It just felt natural.
Tailwind CSS killed design indecision. I did not spend a minute debating whether to use 14px or 16px for body text, or what shade of gray to use for borders. Tailwind has sensible defaults and I just built with them. The result looks clean and professional. People who see Landager for the first time usually ask if I had a designer. I did not. Tailwind plus a clear vision of what “premium” looks like was enough.
Having a clear scope saved everything. I knew exactly what the MVP needed: properties, units, tenants, leases, rent tracking, maintenance, expenses, and documents. I also knew what it did NOT need yet: AI features, internationalization, tenant screening, automated reminders. Those all came later (some during the 10 days, some after). If I had tried to build everything at once, ten days would have turned into three months. Easily.
This is probably the most important lesson. Scope discipline is what separates a ten-day build from a never-ending project. Every developer I know has at least one project sitting unfinished because they tried to build the “complete version” before shipping anything. Do not do that. Ship the core. Then iterate.
What I Would Do Differently
Honestly? Not much in terms of the big decisions. The stack was right. The architecture was right. The deployment approach was right.
If I could go back, I would have separated the dashboard into its own repo from day one instead of doing it on day eight. I started with everything in one codebase because it was faster initially. But once the dashboard grew, it became clear it needed to be its own app. The migration itself took most of a day. Could have avoided that entirely if I had just started with two repos.
I also would have set up proper error handling and logging earlier. During the build, I mostly relied on console.log and browser dev tools. That works fine when you are the only user. Once real people start using the product, you need proper error tracking. I learned this the hard way on launch day when a user hit an edge case I had never tested and I had zero visibility into what happened.
And I would have written the seed script earlier. Having realistic test data in the dashboard from day one would have helped me spot UI issues faster instead of staring at empty states for the first week. When your dashboard shows “0 properties, 0 tenants, $0 collected” it is really hard to judge if the layout and typography look right. Seed data fixes that problem immediately.
The Takeaway
I am writing this on March 18th, 2026. My first commit was on March 9th. That is ten days ago. In those ten days, while holding down a full-time job, I built a complete property management SaaS with a marketing site, a dashboard, an admin panel, payment processing, 33 languages, an AI assistant, tenant screening, PDF reports, and 495 pages of documentation. More details on the ones not mentioned in this post will be coming in another one. It is deployed on my own VPS, accepting users, and launching on Product Hunt tomorrow.
I am not saying this to impress anyone. I am saying this because a year ago I would not have believed it was possible either. The tools we have today as developers are genuinely different from what we had even two years ago. A single developer with a clear idea, a good stack, and the right AI coding agent can ship a real product in a timeframe that would have sounded insane not long ago.
You do not need six months, a co-founder, or venture capital to build something real. You need a clear problem, a stack you know well, a clean database schema, the right AI tools by your side, and the discipline to ship before it is perfect.
Ten days. Full-time job. One developer. One very capable coding agent.
If you have been sitting on an idea, just start. Seriously. Pick this weekend. Set up the project. Design your schema. Build the first screen. The rest follows. It always does. The hardest part is the first commit. Everything after that is momentum.
Landager is live at landager.com if you want to see how it turned out. And if you are a developer building something of your own, I would genuinely love to hear about it.
Top comments (0)