How I used Lovable for the UI, Codex for functionality, and my full-stack background to build an appointment scheduling SaaS after hours.

1*kUGRZFIAFvJ_-Sj3ANhYzw.png

In early 2026, I built and launched a fully functional SaaS product in one month.

Not full-time.

Not with a team.

Not with funding.

I built it at night, after my kids were asleep, using my personal (slow) laptop and my own OpenAI account (with rate limit).

The product is Your Calendar , a scheduling tool that lets people create booking links, share availability, and accept round-robin or multi-host meetings. It is free appointment scheduling software for teams and solo professionals.

The stack was simple: I used Lovable for the UI, then used Codex to add the functionality that turned the interface into a real product.

Why I Started With Lovable

I chose Lovable because the UI output is solid.

For a SaaS product, the first version needs to feel usable quickly. It does not need to be perfect, but it does need to look like something people can trust.

Lovable helped me get there fast.

It gave me a clean starting point for the product experience: pages, layouts, components, and flows. Instead of spending nights designing buttons, forms, and empty states from scratch, I could focus on the product itself.

That mattered because I was building in small windows of time.

Most nights, I only had a couple of hours. I needed tools that removed friction.

Where Codex Made the Difference

Codex changed the way I build software.

Before using tools like Codex, building a SaaS meant sitting down and writing every part of the implementation myself. The frontend, the backend, the API routes, the small fixes, the edge cases, the refactors.

With Codex, my role changed.

I became more of a code reviewer.

I would describe what I wanted, let Codex propose the implementation, then review, adjust, and guide it like I would with another developer. That shift was huge. I was still responsible for the product, the architecture, and the quality of the code, but I was no longer typing every line from scratch.

That made a big difference when I was building at night in small windows of time.

Some nights, I did not have the energy to start from a blank file. But I could still explain the next feature, review what Codex produced, and move the product forward.

How I Structured the Project So Codex Could Build Faster

One thing that made a big difference was how I structured the project.

Instead of splitting everything across multiple repos, I kept the landing page, frontend, and backend in the same folder.

At the root of the project, I added a simple .md file that explained:

what each folder was for
how the frontend and backend interacted
what the product was supposed to do

That gave Codex context.

When I asked for a new feature, it could understand what needed to change across the entire system, not just one part of it.

This meant it could:

update backend logic
adjust frontend components
keep everything consistent

…without me having to explain the architecture every time.

It sounds simple, but this made a huge difference in speed.

My Developer Background Still Mattered

The biggest lesson was this: AI tools are powerful, but experience still matters.

Having a full-stack development background played a huge role.

I already knew what tech stack I wanted. I knew how to structure the app, how to think about deployment, where things usually break, and what trade-offs mattered.

I did not need AI to decide everything for me.

I needed help building faster.

That distinction is important. Lovable and Codex did not replace my technical judgment. They amplified it.

My experience with React and Next.js also helped a lot. The more precise I was with UI language, the better the results were.

For example, asking Codex for a “drawer” worked better than asking for “a card on the right side of the screen.” Asking for a “modal” worked better than saying “a floating card for selecting options.”

Codex is powerful, but it works best when you know how to speak its language.

What Your Calendar Does

Your Calendar helps people schedule meetings without the back-and-forth.

You can create booking links, share your availability, and support different scheduling workflows like one-to-one meetings, round robin meetings, and multi-host meetings. It is built for solo professionals, consultants, creators, and teams who need simple appointment scheduling software without unnecessary complexity.

With round robin meetings, bookings are automatically distributed across a team based on availability, so no single person gets overloaded. With multi-host meetings, only time slots where all required participants are available are shown, making it easy to coordinate meetings that involve more than one person.

The goal is straightforward: make scheduling meetings easier.

Instead of asking, “What time works for you?” and waiting through five messages, you send a link. The other person chooses a time. The meeting is booked.

Building SaaS Is More Accessible Than Ever

A few years ago, building a SaaS product in one month during spare time would have been much harder.

You would need more design time, more development time, and probably more money.

Now, the bottleneck has changed.

The hard part is no longer just writing code. The hard part is knowing what to build, how it should work, and how to ship it.

That is where domain knowledge, product thinking, and technical experience still matter.

AI can help you build faster, but you still need taste. You still need judgment. You still need to know when the generated code is good enough and when it needs to be rewritten.

Final Thoughts

Using Lovable and Codex, I was able to build a real SaaS product in one month, working only at night after my kids were asleep.

Lovable helped me move fast on the UI.

Codex helped me add the functionality.

My full-stack background helped me make the right decisions.

The result is Your Calendar , a simple way to create booking links, share availability, and accept round-robin or multi-host meetings.

If you are a developer with an idea, this is probably the best time we have ever had to build software on the side.

Not because AI does everything for you.

Because it helps you get further with the time you already have.