Cowork.lk: A Booking Engine Built to Never Double-Book and Never Miss an Invoice
Real-time availability, PayHere payments, and Zoho Books sync for a Sri Lankan coworking space
Knovik designed and built Cowork.lk's booking engine from a technical specification: real-time availability across hot desks, dedicated workspaces, and meeting rooms, guest and member checkout with PayHere payments, automatic Zoho Books invoicing, a 10% loyalty discount engine, and a full front-desk admin dashboard — verified end-to-end against real infrastructure, not just a passing build.
Overview
Cowork.lk runs a coworking space in Pannipitiya, Sri Lanka, with six bookable space types, from single hot desks to multi-seat meeting rooms, each with its own pricing and inventory. Knovik was engaged to build the booking engine from an existing technical specification: real-time availability that accounts for overlapping time slots (a half-day booking blocks the relevant half of a full-day slot, and so on), guest and member checkout with Sri Lanka's PayHere payment gateway, automatic invoice creation in the client's existing Zoho Books account, a loyalty discount for returning members, and a front-desk admin dashboard for staff to view availability, manage bookings, and take walk-in payments. Every piece was built and then verified against a real, running instance of the system, real signups, a real simulated payment webhook with a correctly computed signature, real database permission testing, not just code that compiled.
Our Approach
What we delivered
Real-Time Availability, Not a Simple Calendar
Availability isn't a single boolean per day. A half-day morning booking and a full-day booking on the same desk have to correctly block each other; a 10-desk hot-desk pool needs a live count, not a yes/no. Built as a single database function both the customer-facing site and the admin dashboard call, so the two never disagree about what's actually free.
Payments and Accounting That Talk to Each Other
PayHere handles the actual payment (cards and bank transfer/QR, with signature-verified webhooks confirming payment before a booking is marked paid); Zoho Books, the client's existing accounting system, gets an automatic invoice and customer record for every confirmed booking, so front-desk staff never re-key a booking into accounting software by hand.
Loyalty and Admin Tooling Built Into the Same System
Returning members get an automatic 10% discount on any booking within 30 days of their last one, calculated server-side so it can't be spoofed from the browser. Front-desk staff get a real-time availability grid, a filterable booking list, and a walk-in booking form for phone/in-person customers, all reading and writing the same data as the public site.
For Technical Readers
Architecture & technical details
The parts that matter to a technical evaluator: how availability correctness was guaranteed at the database level, and where real bugs were found by testing against a running system rather than trusting a green build.
Availability as a single source of truth, not duplicated logic
A Postgres function (check_availability) owns the overlap rules for every space type — a full-day booking correctly blocks both the morning and afternoon slot; an "unlimited" booking blocks everything under it. Both the customer checkout flow and the admin dashboard call this same function via Supabase RPC, so there's exactly one place that logic lives. Two features (public booking, admin walk-ins) can never silently disagree about what's available, because they're not two implementations of the same rule.
Three real permission bugs, found by testing against a real database — not by reading the schema
Row-Level Security in Postgres is easy to get subtly wrong in ways that only surface under real queries. This build found and fixed three: (1) a database function using the caller's own role instead of an elevated one, which meant an anonymous visitor checking availability was silently blocked by the same policy protecting private booking data, showing every slot as falsely fully booked; (2) Supabase's service-role key, meant to bypass row security entirely, still needs the underlying table GRANT — missing it meant every backend write silently failed; (3) a self-referencing admin policy ("can this user see all bookings if they're an admin" checked via a query against the very table being protected) that Postgres correctly rejects as infinite recursion. All three were caught by running real queries against a real local database, not by reading the SQL and assuming it was correct.
Third-party integrations degrade, they don’t crash the booking
Zoho Books and PayHere are both external services outside this system's control. Every integration point checks its own configuration first and fails closed with a clear, logged message rather than throwing: a booking still completes correctly even if Zoho's API is unreachable or its credentials aren't set up yet, with the accounting sync simply queued for the next attempt instead of blocking the customer's payment.
Payment confirmation is signature-verified, not trust-the-redirect
PayHere confirms payment via a server-to-server webhook carrying an MD5 signature computed from the merchant secret; a booking is only marked paid after independently recomputing and matching that signature server-side; a request with a valid-looking but incorrect signature is rejected before it can touch booking state. Verified by simulating both a correctly signed and a tampered webhook call against the running system and confirming each was handled correctly.
The People Behind This Work
Our experts behind this case study
Madusanka Premaratne
Founder & CEO
Author of the EICON 2026 paper on agentic systems; leads Knovik's edge AI and automation practice, including EdgeTal.
View ProfileIroshana Wickremasingha
VP Engineering
Leads Knovik's web, backend, and eCommerce engineering practice, with a focus on scalable architecture and infrastructure.
View ProfileDelivered & Verified
Results, as of July 2026
This system hasn't launched publicly yet, so what's below is what was actually verified during the build, not projected business outcomes.
Full guest-to-payment-to-invoice flow verified end-to-end
A real booking, a real simulated PayHere webhook with a correctly computed signature, and a real (locally configured) Zoho invoice attempt, confirmed working together, not tested as separate pieces.
Three production-grade database security bugs found and fixed
Each one found by running real queries against a real database under real conditions (an unauthenticated visitor, an admin action), not caught by reading the schema.
Zero data loss through a real infrastructure incident mid-build
A disk-space issue during development left the local database's Docker containers unresponsive; recovered with every previously-created test booking still intact, verified by row count before and after.
Loyalty discount matched the client’s own worked example exactly
The 10%-within-30-days member discount was checked against the client's own specification numbers and matched to the exact currency amount, not just "roughly correct."
Beyond This Client
Where this same approach fits
The specific business is a coworking space; the underlying problem — multiple bookable resources, real-time availability, payment collection, and accounting sync that all have to agree with each other — shows up anywhere a business takes reservations against limited capacity.
Salons, spas & barbershops
Multiple chairs/rooms, staff-specific availability, and no-show deposits work the same way a multi-desk coworking pool does: capacity that needs a live count, not a shared calendar app.
Clinics & wellness practices
Appointment slots per practitioner, intake details captured at booking time, and automatic invoicing to whatever accounting system the practice already runs on.
Equipment & vehicle rental
Inventory-based availability (how many units are free right now) is exactly the hot-desk-pool problem, just with a different noun for what's being booked.
Photo, video & recording studios
Hourly/half-day/full-day pricing tiers on the same room, the exact overlap-blocking problem this build solved for coworking meeting rooms.
Tutoring centers & test-prep
Per-session bookings, package/loyalty pricing for returning students, and a front-desk view for staff taking walk-in or phone enrollments.
Event venues & function halls
Multi-hour or full-day bookings against a small number of physical spaces, where a single double-booking is a serious, visible failure, not just an inconvenience.
Related Services
The services behind this work
Frequently Asked Questions
Got questions? We have answers
Taking reservations for limited capacity, and tired of double-bookings?
Talk to our team about a booking system built around how your business actually takes reservations and gets paid, verified against real conditions before it ships.