Book a Free Call
No commitment required
TL;DR: We built a scavenger hunt app for our team trip in days. Go, HTMX, SQLite. The real takeaway: in 2026, you can build exactly what you need with AI. But you still have to make the hard architecture calls yourself.
Every year, the Wawandco team takes a trip together. We call it La cumbre. The goal is simple: get everyone in the same place, do something fun, and remember that we are humans who happen to write code, not the other way around.
This is not just a vacation. Google’s Project Aristotle study, a two-year investigation into team effectiveness, found that psychological safety, the trust and shared context built when people actually spend time together, is the single biggest predictor of a high-performing team [2]. Retreats do not fix dysfunction, but they do create the conditions where teams can communicate more directly and take the kind of risks that lead to better code.
This year we wanted a scavenger hunt at Parque del Café. Teams would solve clues, upload photos, scan QR codes, and race against a live leaderboard. The problem was we could not find a tool that worked the way we wanted. Existing scavenger hunt apps were either overbuilt for corporate HR teams or too flimsy for a group of engineers who would break anything with a weak auth model.
So we built Scavo. And we built it the way we build everything when the constraints are clear: simple, explicit, and open source.
Scavo is a web app. Players log in with a personal ID. No OAuth. No password reset flow. No email verification. We know every person who will use it because they are sitting in our Slack. The organizer creates the IDs in the admin panel and hands them out at breakfast.
Teams solve mixed-media clues. Some are text answers. Some require photo uploads. Some are QR codes hidden around the venue. Submissions are scored automatically. A live leaderboard updates in real time. Organizers can set time limits, close submissions, and manage everything through a simple admin interface.
The whole thing is a single Go binary with an embedded SQLite database. One VPS. One Docker container. One Kamal deploy.
This is not a stack you would pitch to a VC. It is a stack you would pitch to yourself when you need to ship something in days and sleep well the night before the event.
We did not use Postgres because we did not need it. One server. One file. No replication, no connection pooling, no operational surface area. SQLite is dismissed too often by teams who think they are building for scale they do not have. We were building for thirty people and three hours. SQLite was the correct choice.
We did not use React because we did not need it. HTMX gives you server-rendered HTML with sprinkles of interactivity. The leaderboard updates via a single SSE endpoint. The photo upload form is a multipart POST with a redirect. The admin interface is tables and buttons. No state to sync, no hydration to debug, no bundle to optimize.
We did not build a user management system because we did not need one. A personal ID and a session cookie. The organizer creates the IDs in the admin panel. We print them. That is the entire auth flow. The time we saved not building OAuth was time we spent making the clues harder to solve.
These are the decisions AI cannot make for you. An AI assistant will happily generate a Next.js app with Prisma, OAuth, and a Kubernetes manifest. It will look impressive in a demo. It will also take ten times longer to build, ten times longer to deploy, and ten times longer to debug when something breaks on the day of the event.
Only you know the context. Only you know that this app will run once, that everyone using it is trusted, and that the stakes are low enough that a SQLite file on a single VPS is actually more reliable than a distributed system.
We used AI coding assistants throughout the build. Boilerplate vanished. Tailwind classes were suggested before we finished typing. The migration runner, the session middleware, the scoring logic all appeared faster than we could have written them alone.
But we still made every architecture call. We chose LeapKit over a heavier framework. We chose SQLite over Postgres. We chose HTMX over React. We chose a simple ID-based login over a full auth provider. The AI wrote the code. We wrote the constraints.
That division of labor is what makes AI-assisted development work in 2026. The tools are fast. The context is still yours. A controlled study by GitHub found developers using AI coding assistants completed tasks 55% faster than those without them, while reporting higher satisfaction and lower cognitive load [1]. The speed is real. The judgment is still yours.
Our CEO presented the idea to our Talent Director. She did not believe it was possible. A scavenger hunt app, custom-built, in time for the trip, with real-time scoring and a live leaderboard? She had seen internal tool projects before. They always took weeks, always required clear specifications, and always missed the deadline.
The CEO showed her the app he built with his hands (and machine, of course). Four hours of hacking by one engineer. She was thrilled. Then she started wondering what else could be facilitated this way.
That is the moment that matters. Not the code. Not the stack. The moment when someone who runs the business realizes that the gap between “we need this” and “we have this” has collapsed to a single afternoon.
We deployed with Kamal on a single VPS the night before the cumbre. The container runs migrations automatically on startup. We mounted a persistent volume for the database and uploaded images. The entire deploy workflow is two commands:
kamal setup
kamal deploy
The next morning, we handed out paper IDs. Teams logged in, solved clues, uploaded photos of questionable quality, and trash-talked each other on the leaderboard. The app worked flawlessly. Nobody got paged. Nobody had to restart the server.
Three hours later, we closed submissions and announced the winners. The app had done exactly what we needed, then its job was over.
We cleaned up the code, added a README, and will open-source it under the O’Saasy license. That means anyone can use the code, modify it, and run it. The only restriction is that you cannot turn it into a competing hosted SaaS offering.
You can find the repo at github.com/wawandco/scavo.
We are not turning Scavo into a product. We are not adding multi-tenancy, a billing system, or a white-label dashboard. It is a showcase. A reference for how we build things when the constraints are clear and the timeline is short.
If you are a CTO or VP of Engineering at a growing SaaS company, you are probably facing a version of this problem every quarter. Your team needs a tool that does not exist, or exists but is wrong for your context. The default response is to buy something, or to spin up a Jira epic and scope it for the next sprint, or to say it is not a priority and work around it for another year.
The alternative is to build it. Not as a product. Not as a platform. Just as a tool that solves a specific problem for a specific group of people in a specific moment.
In 2026, the cost of building that tool has dropped dramatically. AI writes the boilerplate. Modern frameworks like LeapKit and HTMX remove the frontend complexity that used to make small projects feel large. SQLite removes the database complexity that used to make small projects feel fragile. Kamal removes the deployment complexity that used to make small projects feel scary.
What has not changed is the need for human judgment. Someone still has to decide whether the app needs Postgres or SQLite, React or HTMX, OAuth or a paper ID. Someone still has to know the difference between a demo and a production system, between a tool that lives for three hours and a tool that lives for three years.
That judgment is what separates teams that ship from teams that debate. AI gives you speed. You still have to give it direction.
Scavo was not a revolutionary engineering achievement. It was a scavenger hunt app for a team trip. The code is straightforward. The architecture is simple. The story is not about what we built. It is about why we built it and how fast it happened.
If your team is spending months on internal tools that should take days, or if you are buying SaaS products for problems you could solve in a weekend, the bottleneck might not be your stack. It might be your tolerance for simplicity.
We built exactly what we needed. Nothing more. It worked. Then we shared it.
Just what worked for us. Your mileage may vary.
Eirini Kalliamvakou, “Research: quantifying GitHub Copilot’s impact on developer productivity and happiness,” GitHub Blog, 2022. https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
Laura Delizonna, “High-Performing Teams Need Psychological Safety: Here’s How to Create It,” Harvard Business Review, 2017. https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it