Alongside client work, we build and run our own products — a hotel property management system, a hospital management platform in pre-launch, mobile apps for traders and farmers, a few games and some AI experiments. People sometimes ask whether that's a distraction from client work. For us it's the opposite: it's the reason our client work holds up after launch.
Launch is the midpoint
When you build for a client and hand over, it's easy to think of launch as the finish line. When you run the product yourself, launch is where the real work starts: the first support message at 7 a.m., the edge case nobody imagined, the feature that seemed essential and nobody uses.
The Vestly, our hotel PMS, made this concrete. A hotel front desk doesn't stop for a deploy. If check-in is slow on a Saturday morning, a real guest is standing at a real counter. That changes how you think about everything from database migrations to error messages.
Lesson 1: Design for the busiest ten minutes
Most software is designed for a calm demo. Front desks, warehouses and clinics have rush hours. We now design every workflow for the busiest ten minutes of the day:
- The most common action is one tap from the home screen.
- Nothing important hides behind a menu during a rush.
- Screens stay usable when the network is slow, and say clearly when something hasn't saved.
We bring this straight into client projects. When we scope a CRM or an internal tool, we ask: what does this screen look like when three things are happening at once?
Lesson 2: The admin is a product too
Early on, we treated settings and admin screens as an afterthought. Then every small change — a new room type, a tax rate, a staff member leaving — became a request to us. Now we build the admin as carefully as the customer-facing side, because the admin is what lets the business run without us.
If a routine change needs a developer, the software isn't finished yet.
That's why our client stores ship with editable sections, and why our business software ships with roles, permissions and an audit trail from the first release.
Lesson 3: Boring reliability beats clever features
The features people praise in demos are rarely the ones they depend on. What they depend on: data that's always there, backups that work, logins that don't lock them out, and a system that behaves the same way every day.
So we invest early in the boring parts:
- Automated backups, tested by actually restoring them.
- Error monitoring that tells us about a problem before a customer does.
- Migrations that can be rolled back.
- A staging environment that mirrors production closely enough to trust.
Lesson 4: AI earns its place in the repetitive work
Both The Vestly and Ortho Scribe use AI, and the lesson has been consistent: AI is most valuable where people do repetitive, structured work — drafting a note, summarising a booking history, filling a form from a conversation — and where a human reviews the output before it matters.
We avoid AI features that look impressive but ask people to trust an answer they can't check. In client projects, we suggest AI where it removes real drudgery and keeps a person in control.
Lesson 5: Small products teach fast
Not everything we build is a platform. Our casual games and small apps are where we try new tools, practise motion and polish, and learn store review and release processes end to end — cheaply, on our own time, before we use them on a client's product.
What this means for clients
When you work with us, you're working with a team that has been paged on a Sunday, has restored a backup for real, and has watched people use software in a hurry. Concretely, that shows up as:
- Scoping that asks about the busiest moment, not just the happy path.
- An admin your team can run.
- Monitoring, backups and a plan for after launch, included rather than upsold.
- Honest advice about where AI helps and where it doesn't.
Building our own products keeps us honest about what software has to do after the launch party. It's the same standard we bring to yours.
Leave a Reply