I'm building a Next.js website for a local plumber. The basic site is currently deployed from GitHub to Vercel, and I already have a contact form working with Resend. I'd like to add an online booking system and give the client a WordPress-style experience for managing blog posts and site content.
I've used Sanity locally before, but not as a hosted service. I'm also considering Railway's roughly $5/month option with PostgreSQL, especially if the project eventually needs Stripe payments, although payments are not confirmed yet. Self-hosting isn't an option.
Another possibility is embedding a service such as Calendly for bookings while using a separate CMS for the blog. The main concern is making the final setup easy for the client to manage after I hand it over. What approach would be the most practical, and are there any pitfalls with using Railway, PostgreSQL, a hosted CMS, or a third-party booking service?
4 Answers
I would separate the content and scheduling concerns. A hosted CMS works well for blog posts and editable pages, while a dedicated booking service can handle calendars and notifications. Your website can make the experience feel unified even if the underlying tools are separate.
If you do use PostgreSQL for bookings, design the data model around optional payments from the start. Treat payment as one possible step in the booking flow rather than making every appointment depend on Stripe, since the plumber may prefer confirming jobs and collecting payment later.
Be careful about handing over a custom-built application just because the client wants a single place to manage everything. A custom booking system can become a long-term maintenance obligation, especially if you are relying heavily on generated code or if the client needs to change working hours, services, and availability without breaking anything.
If the client genuinely wants a familiar WordPress-style editor, using WordPress with established booking and payment plugins may be more practical than recreating that experience in Next.js. If you stay with Next.js, document the deployment, backups, environment variables, account ownership, and recovery process from the beginning.
Railway with PostgreSQL should be perfectly adequate for a small business site. The difficult part of a booking system is not scaling the database; it’s handling double bookings, availability rules, cancellations, reminders, rescheduling, and permissions.
I’d begin with a booking request form where the plumber manually confirms the appointment instead of offering fully live availability. That avoids a lot of calendar complexity and may actually fit the way a local tradesperson works. You can add payments later without making the first version depend on Stripe.
The biggest question is not which database or hosting provider you choose, but who will maintain the system after you hand it over. A setup that is inexpensive and convenient for you to build may still be difficult for the client to manage.
For bookings, an embedded service such as Calendly already handles much of the difficult work and may have an API available if you need a custom presentation. The blog can live in a separate CMS. Keeping those responsibilities separate is often safer than building one large system that tries to behave like both WordPress and a scheduling platform.
That makes sense. Since the client mainly wants everything to feel like one website, I’m leaning toward using a hosted booking tool for the scheduling and a separate CMS for the blog rather than building the entire booking system myself.
That’s a helpful approach. Starting with appointment requests and manual confirmation would let me validate the workflow without having to solve every calendar edge case immediately.