Building the Team
We hired generalists. At the early stage, the team needed people who could work across the entire stack rather than specialists who would sit idle when their narrow area of expertise was not the bottleneck. A small team of capable generalists moved faster and adapted more readily than a larger team of specialists would have.
This was a deliberate choice. When you are building from nothing, every person needs to contribute across multiple dimensions. The luxury of specialisation comes later, once the product and team have reached a certain scale.
"At the early stage, the team needed people who could work across the entire stack rather than specialists who would sit idle."
Reliability as a Feature
We treated reliability as a core product feature, not a technical afterthought. Students writing dissertations depend on their tools at the most stressful moments of their academic lives. A citation tool that goes down during submission season does not get a second chance.
This meant investing in infrastructure and monitoring earlier than a typical startup might. It felt like over-engineering at the time, but it paid off. Users trusted RefME because it was there when they needed it.
Saying No to Feature Creep
Citation accuracy was RefME's core value proposition. Every feature request was evaluated against a simple question: does this make citations more accurate, faster, or easier to generate? If the answer was no, we said no.
This discipline was essential. The temptation in any consumer product is to keep adding features to match competitors' checklists. But business-first engineering means understanding that focus is a competitive advantage, not a limitation.
"Focus is a competitive advantage, not a limitation."
Scaling to Two Million
Growth brought a different set of challenges. Infrastructure that worked for ten thousand users buckled under two million. We had to rethink caching, database architecture, and deployment processes. The team structure evolved too, moving from a handful of generalists to a more structured operation that could handle the demands of a product with real scale.
The key lesson was that scaling is not just a technical problem. It is an organisational one. Processes, communication patterns, and team structure all needed to evolve alongside the infrastructure.