The Cloverly Stack: What We Built It On, and Why

Hey all. I'm Ryan, a founding engineer at Cloverly, an early-stage B2B SaaS: a sales & reservation system for Philippine property developers. It's live, with pilot customers running real sales on it. We went through IdeaSpace Cohort 13 last year, and we're now backed by the DOST-TAPI program.

At Code Vertical, I built software for businesses with very different needs, but the problems behind them were often surprisingly similar. Many were trying to move away from fragmented workflows, spreadsheets, and manual processes that had grown over time. Building Cloverly felt like a natural progression from that experience. It’s the same work I've always enjoyed: getting close to the problem, understanding how people actually work, and building software that becomes part of their day-to-day operations.

Everyone's building in public now with the newest frameworks, AI and agents, and that's where we're headed too. But foundations first: Cloverly is a Laravel app, the stack my team and I know best.

Laravel core: Inertia + Vue for the front-end

Laravel is the brick and mortar of everything I've built. The first few years at Code Vertical it was a PHP core with vanilla JS and Blade; it's since grown into the VILT stack (Vue, Inertia, Laravel, Tailwind) we use today. I've pushed it through the parts that bite in production: queues and background processing, batch jobs, scheduled tasks, caching, third-party integrations, and the performance tuning that only shows up once real businesses are running on it. Eight years in, I know where Laravel is strong, where its trade-offs show, and how to design around them.

On the frontend, Inertia is the piece that changed how we build. You get the single-page feel without maintaining a separate API for the web; the web app talks to controllers directly. The API we expose is for our Flutter app, with Sanctum and JWT for auth.

Because the stack is familiar, our days go to the workflows customers live in and the AI pilot we're just starting on, not to fighting the framework. It's not frozen, either: we run the latest Laravel and keep packages current.

Design: the complexity is ours, not the user's

The business behind a property developer is complex. Inventory across projects, reservations, approvals, payment milestones, sales moving between people who all need to trust the numbers, and all of it live at once. That's the workflow Cloverly takes on.

So on the surface, we keep it simple. Each screen shows only what matters for the step you're on, and the next thing to do is always obvious. You can see where you stand at a glance: what's approved, what's pending, what's left. Nobody should have to hold the whole process in their head.

We listen closely to our users, but the discipline is in how we answer. More often than not the right move is to cut something, not add a feature. That's less for them to learn and less for us to maintain.

The boring infrastructure

We keep the infrastructure boring on purpose. Code ships through GitHub Actions, backups run on a schedule, and the app stays a monolith built around service and action classes, which we'll only split apart when scale forces it.

Cloverly is multi-tenant: one product serving many property developers, each with their own projects, inventory, and numbers. We give every tenant its own database, which keeps each dataset lean, queries fast, and one client's data fully isolated from the rest.

Spatie's packages have done a lot of the heavy lifting: laravel-multitenancy for tenant routing, laravel-permission for roles and access, which we enforce through Laravel's own policies and gates, laravel-activitylog for an audit trail of who changed what, and laravel-query-builder for data-safe filtering, among others.

We're a Google Cloud Partner and run on GCP, with Cloud Armor in front. Queues run through Horizon, real-time over Reverb, and push notifications through Firebase to the Flutter app. For visibility we lean on Cloud Logging and Cloud Monitoring, and we're still working out how much alerting we actually want.

AI, only where it earns its place

Agentic coding is still new for us, but it's come a long way fast. Laravel Boost grounds the agents in the real shape of our app and version-correct docs, and Claude and Codex do the coding on top. It's a real speed-up, from grilling the spec and plan, through the coding itself, to tests and the feedback loop. But our foundation stays in the loop: we review what the agents produce before it ships.

Inside Cloverly, the AI we've shipped is still experimental and stays on the surface: a check when a document comes up for approval, and search that goes by meaning, not exact words. The one we're wiring up goes deeper: an agent that reads a buyer's reservation agreement, builds the context around it, and proposes the next step. The discipline is the same as everywhere else in the product: we push autonomy only as far as a property developer actually needs it, not as far as the tech allows.

How we keep it from breaking

We test by risk: every critical workflow is covered by Pest. Pint and Prettier keep our formatting consistent, and ESLint catches problems before they land. It's early, but that coverage is what lets us keep changing things without breaking what people already rely on.

Where this goes next

So that's the stack. A small team moves faster on a foundation it already knows, and I'd rather be honest about where we are than oversell it.

What happens next isn't really up to us. We're building it alongside our pilot customers, watching where it genuinely takes work off their plate and where it doesn't. That's what decides what comes next: which workflows to deepen, and how far to push the autonomous side.