Building Hospiq: How a Pricing Dispute Made Me Open-Source a Hotel System

This one started with a guest checking in.

Dipatnu Chakraborty, the CTO of Aaharan Edu Smart, was staying at Geetanjali, a government guest house in Tripura. Somewhere during the stay he asked the question that ends up behind half the software in the world: do you have anything to manage all of this? They did not. Geetanjali is a guest house, not a tech company — front desk, rooms, and a restaurant, all run the old way. He connected them to me, they handed over how everything worked, and I built them a system for it.

That system became Hospiq.

What Hospiq does

Hospiq is a single suite that runs both halves of a hospitality business, which usually live in two separate, badly-integrated tools — if they exist at all:

• Front desk & rooms — an interactive room grid with types and housekeeping status, guest check-ins, occupancy at a glance.
• Restaurant — interactive table mapping, live Kitchen Order Tickets (KOT) streaming to the kitchen in real time, and a QR self-ordering portal where a guest scans the code on their table and orders from their own phone.
• The brain — a real-time dashboard tying rooms and restaurant revenue together, role-based access for staff vs. management, and business intelligence that actually updates as the day happens.

Next.js 16, React 19, Supabase/PostgreSQL, Redis for caching, all self-hostable.

The question that changed the deal

Here is the twist that taught me the most, and it had nothing to do with code.

Once it was built, they asked what sounded like a simple question: how much to keep one year of data backed up? I did the mental math on a 20-room guest house and shrugged — hotel bookings for one small property is barely any data, comfortably inside a Supabase free tier. So I said, essentially, free.

Then came the second half of the sentence: they also wanted a year of restaurant receipts backed up. That is a completely different animal. Receipts pile up fast, and keeping a queryable year of them properly means real storage and a real server — a full VPS hosting solution, not a free tier. So the honest answer flipped from "free" to "around ₹1,500 a month, ongoing." Nobody loves hearing a free thing now has a monthly bill, and a disagreement followed.

We settled it in an unusual way. I took less money than we had originally agreed to soften the hosting cost for them — but in exchange, I kept complete ownership of the project. At the time it felt like a compromise. It turned out to be the best deal I ever made.

Why that ownership mattered

Because I owned it, Hospiq did not end at Geetanjali.

I took the same system to two more local hotels for a lump sum each — work I could only do freely because the code was mine, not locked to one client's contract. One build, sold three times, each time a little more refined. Owning your work is not an ego thing; it is the difference between getting paid once and building an asset.

The backup dispute also left a permanent mark on the engineering. That "one year of data" requirement is exactly why Hospiq has an automated data-retention pipeline — a pg_cron job that batch-deletes records older than a year in controlled chunks, so the database does not balloon forever and the hosting bill stays sane. A business argument became an architecture decision.

The engineering I'm proud of

Under the hood, the parts that took real care:

• Atomic stock transactions. When a guest orders from their phone and the kitchen accepts it, stock has to be checked and reduced without two orders racing over the last portion. I pushed that into PostgreSQL procedures so the check-and-reduce happens atomically in the database, not hopefully in the application layer.
• Redis caching with versioned keys. Rather than hunting down and deleting cache entries when data changes, I version cache keys per domain — bumping the version instantly invalidates a whole slice without expensive scans. Stale reads resolve fast.
• Real-time KOT. Orders stream from a guest's phone to the kitchen screen live, so the kitchen sees the ticket the moment the guest hits send.

Why I open-sourced it

After the third hotel, a friend said something that stuck: this is genuinely useful, and there is almost nothing out there that self-hosts a hotel and restaurant system together — you can go make it open source.

And the more I sat with it, the more it felt right. I build my entire career on open-source tools. Next.js, Supabase, Redis, every library in the stack — other people gave those away, and I have taken from that well constantly. Releasing Hospiq under Archilect was a small way of putting something back into it. So it lives on GitHub now, MIT-licensed, for the next small hotel that cannot afford enterprise software.

None of that would have been possible if I had not, months earlier, taken less money in exchange for owning what I made.

Where it stands

Hospiq runs in real hotels — it started at Geetanjali and went on to two more properties — and it is open source and self-hostable for anyone else who needs it. Honest status: shipped, in production, and public.

What I took from it

The technical lessons were real — atomic transactions, cache invalidation, retention pipelines. But the one I actually repeat to myself is about the negotiation, not the code: sometimes the right move is to take less cash and keep what you built. The money you turn down once can become an asset you sell three times and give to the world on the fourth.