Simple and scalable.
That’s how the engineering team at Playground, a childcare operations software company, approaches product builds.
Ricardo Rivero, staff software engineer, explained that the product team focuses on shipping simple changes that can be scaled down the road rather than over-optimizing before they need to.
“In practice that means designing for today, the three-month and 12-month solution concurrently,” Rivero said.
Built In spoke with Rivero about how the engineering team at Playground ships to minimize chaos and ensure success for the long haul.
Playground is a platform for childcare providers to streamline their operations.
What’s your rule for releasing fast — and what KPI proves it works?
Keep it simple and iterate. I try not to over-optimize before I need to, but I do take care that whatever I ship today can be built upon later, instead of thrown away because it doesn't scale. In practice, that means designing for today, the three-month and 12-month solution concurrently.
The KPI I watch is deployment frequency and how long it takes to go from writing a ticket to merged pull request. If I can't ship at least a slice of the solution without many iterations, it signals I might need to start over from first principles. If I over-engineer, lead time expands. If I cut corners, revisions and follow-ups spike. When I'm iterating well, both stay healthy at once.
Which standard or metric defines “quality” in your stack?
No silent failures. The bugs I worry about are the ones tests don't catch: timezone handling, legacy client support, permissions. All of that can be green in continuous integration and quality assurance and still broken for real people.
So, the metric I actually trust is our unhandled-error rate in Sentry and the number of users affected. We set up alerting so that we only get paged for things we didn't anticipate. Expected states get handled and stay quiet and genuine silent failures don't drown in noise.
Name one recent AI/automation shipped and its impact on the team or business.
Our skills repository. The idea is to take expertise and best practices and encode them into a reusable, shareable format. Once a pattern is a skill, correctness is baked in and an agent can actually build features end to end. This increases consistency and development velocity tremendously.
But the biggest unlock is sharing skills with the team. Other engineers have access to project patterns, conventions and industry experience that used to take months or years to acquire. There's a misconception that agents struggle with large/established codebases and it's easier to create greenfield projects with AI. When you have a strong repository of skills, I would vouch that the opposite is true.
