Case study · Ruta
What I've built inside Ruta.
Ruta is service-management software for landscaping and maintenance businesses — one platform carrying a job from the first rate request to the final payment. I did not start it, and it is not my company. I helped build it: since April 2026 I have shipped across all four of its apps and the AWS backend they share.
Four apps over one backend
An owner, a crew member, and a homeowner want completely different things from the same job, so each has their own app over shared data. I work in all four, which is the reason a single change of mine often touches the backend, the office screen, and the field screen in one pull request.
Office web app
Owners and dispatchers
Where the day gets run: customers, the schedule, billing, and messaging in one place.
Crew app
Field crews, iPhone and Android
Published as Ruta Crew. The day’s work and the time clock — and it keeps working when the signal drops.
Customer portal
Homeowners and property managers
Self-service: approve work, settle a balance, and look back over past visits.
Admin console
The Ruta team
The internal side — onboarding new companies and supporting live accounts.
The screens I work in
The office app and the customer portal
Two React apps over the same data: the dispatcher's control room, and the self-service view a customer gets. Sketched here rather than screenshotted, because real customer data sits on every live screen.
The office home screen — the day's visits, revenue, who is clocked in, and what needs a decision now.
The customer portal — active services, a balance to pay, and more work to request.
The work
What I've shipped, by area
Everything below went into production. It is a summary rather than a list — years of changes do not fit on a page, and the details of a client's product stay with the client.
Billing and money
The part of the product where a bug costs someone real money, so it gets the most care.
- Automated recurring billing, so the money collects itself instead of being chased
- Flexible payment arrangements a customer can follow and settle on their own
- Revenue forecasting from the live schedule, so an owner knows what next month is worth
The crew app in the field
A crew will abandon an app that loses their work. Most of this is reliability, not features.
- Offline that feels no different from online, syncing the moment signal comes back
- Time tracking dependable enough to run payroll from
- A verifiable record of every visit, captured on the job rather than written up later
The office web app
Where owners and dispatchers spend their day, and where most of my changes land.
- Customer messaging brought inside the platform, so the conversation lives with the job
- A live map of the day — every property being served, and every crew out working
- An approval step between the work being finished and the customer being billed
The customer portal
Self-service that has to be understandable by someone who has never seen the product.
- Customers settle up themselves instead of calling the office
- Requests for more work come in through the portal and land straight in the schedule
Backend and platform
The AWS side: the data model, the scheduled jobs, and the plumbing everything else sits on.
- Location and job-site intelligence handled once on the backend, shared by every app
- The scheduled automation the whole platform leans on, made dependable
AI, in production
I built Ruta AI into the product — and it does the work, not just the talking
Ruta AI runs on Amazon Bedrock and I shipped it across the web app, the backend, and the crew app. The point was never a chat box bolted to the corner of the screen: it answers from the company's own records, and it can act on what it finds.
What I shipped
- Answers grounded in the company’s own records, found by natural phrasing rather than exact keywords
- It acts as well as answers, and can take a user straight to the right place in the app
- Draft replies written from real history, which a person edits or regenerates before anything is sent
- Available everywhere people already work — the office app and the app in the field
What that means for your software
The same work, pointed at your product — grounded answers, actions with a person in the loop, and cost/failure handling built in from the start.
Grounded in your data, not the internet
The useful version of this reads your own records and answers from them. That is a retrieval problem before it is a model problem, and it is most of the work.
Actions, with a person in the loop
Drafting, sending, approving, scheduling — the model proposes and a human confirms. Nothing irreversible happens on its own.
Built to fail politely
Timeouts, a model chosen per task rather than the most expensive one everywhere, and errors a member of staff can understand and act on.
AI in the workflow, not just the product
The team’s own way of working, too: production problems explained in plain language, and internal tooling that saves engineering time.
Built with
A TypeScript monorepo on AWS
One language end to end: React on the web, React Native through Expo on phones, and a serverless AWS backend behind them, with the infrastructure itself defined in code. The assistant runs on Amazon Bedrock. Payments, maps, and search go through managed services rather than anything hand-rolled.