Casa Basilico · Co-founder, tech + ops · 2023 — present
Casa Basilico — what an early-stage CTO actually ships
A pop-up coliving operation across four locations, hundreds of guests, and a single VPS. Built reactively, only after spreadsheets broke. The case for staying small longer than feels comfortable.
What it is
Casa Basilico is a pop-up coliving operation my co-founder and I started in early 2023. We open a house for a season, fill it with digital nomads, close it, move. We’ve run four locations and hosted hundreds of guests through the platform.
She owns social and front-of-house. I own tech, ops, and most of the marketing engine behind it.
What it isn’t
It isn’t a SaaS startup. There’s no roadmap, no investors waiting on a deck, no PMF question. The software exists to make our actual business — running houses — possible. That distinction shaped almost every technical decision below.
When the software started
Not at the beginning. The first season ran on a spreadsheet, a shared inbox, and a calendar that we updated by hand. The booking software arrived when manual ops broke — when I could no longer hold the state of inquiries, deposits, calendars, and guest comms in my head between coffees.
If I could rewind, the only thing I’d change is starting to build sooner. Every week of “we’ll do it manually for now” was a week of compounding mistakes I had to clean up later. The instinct to defer building software is correct for products you might not ship. It’s wrong for the operational backbone of a business you’re already running.
Stack
A Go service plus Postgres on a single Hetzner VPS. A couple of background workers for sync jobs, reminders, and the email queue. Caddy in front for TLS. The admin dashboard, internal tools, and the booking app all live on the same box. Total monthly infrastructure cost is in the low double-digit euros.
The frontend is an SPA. With hindsight I’d have used server-rendered HTML — the SPA is the one piece of the stack that pays ongoing complexity tax for benefits we don’t really use.
Three decisions worth explaining
Bought, not built: Stripe Checkout. The temptation to build a custom payment UI is enormous because payments touch every other part of the system. I resisted it. Hosted Stripe Checkout costs me a small UX compromise and saves me PCI scope, dispute UI, refund flows, and roughly an entire engineering quarter I do not have. For any founder asking the same question: if your product isn’t a payment product, use the hosted checkout.
Built, not bought: the guest CRM. This is the opposite story. Off-the-shelf CRMs are built for outbound sales pipelines. Casa Basilico is inbound — guests find us, ask questions, get a quote, pay a deposit, arrive. The state machine is small, specific, and deeply tangled with the booking calendar. A generic CRM forced our shape into theirs and cost more in workarounds than building it. Two thousand lines of Go now do what HubSpot couldn’t.
Skipped: real auth and a mobile app. We have one operator (me) and one helper (her). We do not need OAuth, role-based access control, or SSO. We do not need a native app for guests who book once a year. Skipping both saved months of work that nobody — guest or operator — would have noticed.
The incident
The one production scare worth telling: a partial data loss caused by a bad query against the bookings table. I caught it within minutes. No guest was affected. No money was lost.
What changed permanently afterwards: off-site automated backups with weekly restore drills. Backups you’ve never restored aren’t backups, they’re hope. The drill — actually pulling the dump down, restoring it on a fresh VM, running a query against it — is the only thing that proves they work. We do it on a cron job. The first time we did it, three things were broken. They aren’t anymore.
What changed in the business
The headline number is occupancy. Before the software, we had to decline inquiries we couldn’t quote fast enough, miscount overlapping bookings, and let nights go empty because we didn’t know they were available. After: directional occupancy is 20–40 points higher than the equivalent first season. Same houses, same prices, same marketing. The difference is operational throughput.
The deeper change is non-numerical: I stopped waking up with the booking state in my head. Software that holds the state for you is the thing that lets a two-person operation breathe.
What this says about how I work
Three patterns to take away if you’re considering working with me as a fractional CTO:
1. I build the smallest thing that holds. Single VPS. Server-rendered when I can get away with it. No microservices, no Kubernetes, no abstraction for tenants we don’t have. The software stack costs less per month than most startups’ Notion bill. The point isn’t frugality — it’s that small stacks fail in legible ways and recover quickly.
2. I separate buy-vs-build by where the IP actually lives. Payments aren’t our product, so we buy. Guest experience and inbound flow are our product, so we build. This sounds obvious, and almost nobody does it cleanly because both temptations cut the other way: founders build payments because it feels like a moat, and use generic SaaS for the part that’s actually their differentiator.
3. I ship operational software early, not late. The single decision I regret about Casa Basilico is waiting to build. Every operational business has a moment where the spreadsheet starts lying to you. The cost of building before that moment is one engineer-week. The cost of building after is months of cleaning up records that no longer match reality.
If those patterns sound useful for the business you’re running, get in touch.