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 clients 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, Vue gives us reactive interfaces and a maintainable structure, while Inertia connects them directly to our Laravel controllers. This gives us the single-page experience without maintaining a separate API layer for the web. Our APIs are primarily built to support the buyer mobile app, built with Flutter, with authentication handled through Sanctum and JWT.

Because the stack is familiar, we spend more time improving the workflows our customers rely on and building new capabilities, including the autonomous agents we're currently exploring. We continue to evolve the platform where it matters, adopting new tools and patterns when they provide real value.

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 we focus on solving the underlying problem rather than simply adding features. Sometimes the best product decision is removing complexity.

The boring infrastructure

We keep the infrastructure boring on purpose. Code ships through GitHub Actions: build a Docker image, push to Artifact Registry, and roll it out to a Google Compute Engine (GCE) instance group, backups run on a schedule, restore capabilities are in place, and the application remains a modular monolith with clear domain boundaries, providing a clear path to domain-driven architecture and microservices as we scale.

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 on Cloud SQL for MySQL, which keeps each dataset lean, queries fast, and one client's data fully isolated from the rest. The cost is real: every schema change runs across all tenants, and cross-tenant reporting takes deliberate work. We accept that complexity because the isolation model gives us stronger data boundaries, improved security, and greater confidence in the reliability of each client's environment.

For the well-solved problems, we reach for the tools the Laravel ecosystem already trusts. Spatie packages handles most it: laravel-multitenancy for tenant routing, laravel-permission for roles and access, laravel-activitylog for an audit trail of who changed what, and laravel-query-builder for injection-safe filtering. Access is enforced through Laravel's own policies and gates, with a handful of other well-established packages filling in around them. Off-the-shelf where the problem is solved, custom where it's ours to own.

We're a Google Cloud Partner and run on GCP, with a load balancer and Cloud Armor, our WAF, in front. Files storage lives in AWS S3, and secrets are managed through Secret Manager. 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 actively investing in better observability, especially actionable alerting.

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-based automated testing. Pint and Prettier keep our formatting consistent, and ESLint catches problems before they land. Work is tracked through Linear, keeping engineering tasks and product priorities aligned. Nothing reaches pilot clients without going through staging first. This foundation gives us the confidence to move quickly while maintaining the reliability and trust our users depend on.

Where this goes next

So that's the stack. A small team moves faster on a foundation it already knows.

What happens next isn't really up to us. We're building it alongside our pilot clients, 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.