7 Years at Olio

TL;DR: I've spent over 7 years at Olio, growing from a mid-level developer to Tech Lead. This post reflects on what I've learned about building products, leading teams, and growing as an engineer; lessons I hope are useful regardless of where you work.

---

When I joined Olio in 2018, the engineering team was just three people, including me. The product was early stage, we were rebuilding the app, and honestly, I had no idea I'd still be here seven years later.

In that time, I shipped a React Native MVP in about three months, helped migrate a large platform from Rails to React, mentored engineers who later led their own features, and grew into a Tech Lead role I never planned for.

This isn't a guide on how to succeed. It's a reflection on what I learned, mostly through experience, about building software, working with teams, and growing as an engineer. I hope some of it feels familiar.

The early days: shipping fast with a tiny team

In the first few months, we built the React Native app MVP in about three months with a very small team. It was intense, and we made trade-offs we probably wouldn't make today. But we shipped, and that app now serves millions of people.

Working in such a small team meant touching everything, from map performance to ads logic. It was exhausting and exciting at the same time.

What I learned:

• Early speed matters, but fundamentals matter more.
• Patterns set early tend to stick unless you actively change them.
• Small teams move fast when there is trust.

Owning the release process

For over four years, I co-owned the mobile release process, coordinating weekly releases for both iOS and Android. It might sound routine, but it taught me a lot about reliability and communication.

What I learned:

• Release management is as much about people as it is about code.
• Automating what you can and documenting the rest saves time.
• Being reliable builds trust, but knowledge should be shared to avoid bottlenecks.

The Rails to React migration

One of the bigger projects was migrating the Volunteer Hub from server-rendered Rails views to a React SPA. It took over two years and happened while the tool was actively used by thousands of volunteers.

What I learned:

• Large rewrites only work when done incrementally.
• Important business logic often lives in unexpected places.
• Migration decisions shape the codebase for years.

Leading a large UI rearchitecture

Later on, I led a rearchitecture of schedule grouping in the Volunteer Hub. The goal was to better reflect how volunteers actually think about their pickups.

This work involved data transformations, UI state, and close collaboration with backend, product, and operations.

What I learned:

• Good technical solutions come from understanding real user workflows.
• Complex features need clear ownership.
• Feature flags and careful rollouts make a big difference.

Mentoring and growing engineers

As I became more senior, mentoring became a bigger part of my role. I paired with engineers on tricky problems, reviewed designs, and helped guide decisions without taking over.

One of the most rewarding parts has been seeing people I mentored grow into confident engineers. Over time, this also meant contributing to shared expectations around code quality, collaboration, and what good engineering looked like, regardless of role or title.

Some lessons here:

• Pairing teaches more than prescribing.
• Asking questions helps people learn better than giving answers.
• Letting go is necessary if you want others to grow.

Developer experience matters

I spent time improving things that are not always visible. Fixing Docker issues, tightening TypeScript, improving templates, and smoothing local setup problems.

Once, a Docker and MySQL port conflict blocked the whole team. Fixing it wasn't glamorous, but it removed friction for everyone.

These investments rarely stand out, but they save time and frustration.

Prototyping and experimentation

Over the years, I built several prototypes. Some shipped, many didn't.

What I learned:

• Prototypes are tools for learning.
• Their value is often in what they prevent you from building.
• I enjoy turning unclear ideas into something tangible enough to evaluate.

Extending to charity volunteers

Expanding the platform to support charity volunteers looked simple at first. In reality, it surfaced assumptions across the system.

It reinforced an important lesson. Impact comes from understanding the business context, not just writing code.

Building partner tools

I also worked on front-end tooling for partners like supermarkets and food businesses. This work came with a different set of constraints, including supporting non-technical users, handling complex scheduling logic, and building interfaces that needed to be reliable and easy to understand.

In many ways, these challenges were consistent across the products I worked on, and reinforced the importance of clear UX, predictable behaviour, and strong collaboration across teams.

Speaking at React Conf

In 2019, I spoke at React Conf about how we built and scaled the Olio app. It was intimidating.

Preparing the talk helped me understand our work more deeply, and the response from the community was generous and grounding.

What I'd do differently

Looking back, there are things I would change:

• Be stricter with TypeScript earlier.
• Invest more in targeted automated testing.
• Document architectural decisions more consistently.

What still drives me

After seven years and multiple codebases, including the consumer app, volunteer tools, partner tools, and some backend work:

• I still enjoy building things that matter.
• I like simplifying complex systems.
• I care about helping people grow.
• I'm excited about using better tools, including AI, to work more thoughtfully.

---

If you're early in your career, I hope this helps. Paths are rarely linear, and some of the most important skills take time to notice.

And if you're mid-career and wondering whether staying somewhere long term makes sense, deep knowledge and shared history can be valuable in ways that are hard to measure.