Case Studies

The need: A spirit-led life coaching practice needed a public presence. Coaching is delivered one-on-one, in groups, and on retreat, and the free-to-attend gatherings are funded by donations — so the site had to sell the coaching without ever making the gatherings read as ticketed.

What we built: A single-page brand site built around the six areas the coaching covers, with every booking routed to the practitioner's own scheduling link. Includes an on-page fit survey: three taps, deterministic scoring, and a result naming where coaching would help before handing off to booking. It collects nothing and stores nothing — the whole thing runs on the visitor's device, so no accounts, database or payment handling enter the app. Giving is presented as scannable codes rather than links, because one of the three providers cannot complete a payment from a web link at all.

Constraints: Free-to-attend messaging cannot imply cost; no payment processing, accounts, or stored submissions on the site; a strict CSP rules out every third-party embed, so scheduling and giving are outbound links and codes

The need: 130 acres in Glencoe, Kentucky, sold through a third-party camping platform with no site of its own. The owner needed somewhere to describe the land properly and send visitors to book.

What we built: A static brand site covering the land, both stays, activities and practical access notes, with each booking call to action routed to its own listing on the existing reservation platform. Attractions are split into on-property and nearby so regional sights are not mistaken for amenities. Every image is the owner's own photography; the cabin has only ever been visualised, so its render carries a visible 'Rendering' badge enforced in the data rather than left to whoever adds the next image.

Constraints: Only confirmed inventory may be listed; no invented cabins or pricing; guests book real stays from this page, so stock imagery of other land was removed outright and renders must be labelled as such; booking and payment stay on the existing platform

anymrkt — channel control plane for stays, rentals, products and sessions

In development

The need: Businesses selling stays, rentals, sessions, and products maintain separate booking flows and calendars per channel. Time-bound inventory conflicts lead to double-bookings.

What we built: A unified control plane for time-bound inventory: bookings, rentals, product/experience sales, and session scheduling. Synchronizes availability across channels so one booking closes dates everywhere. Multi-tenant by design.

Constraints: Multi-tenant from the start; no tenant-specific branches; relies on third-party calendar feed availability