Lessons Learned in Purpose-Driven ECD App Development

By Tracey Chambers, Founder of Grow ECD

In 2022, responsibility for ECD shifted from the Department of Social Development to the Department of Basic Education. Since then, early learning has taken centre stage, with greater recognition of its role in shaping long-term educational outcomes.

This transition also highlighted the need for ECD centres to have the right tools to deliver quality care and education. That's where organisations like Grow ECD and solutions like the Giraffe app play an essential role.

When we began developing Grow Giraffe, the aim wasn't simply to create another management app. The vision was to design a purpose-driven solution that would meaningfully improve the lives of teachers, principals, and the children they serve.

Today, Grow Giraffe is South Africa's most widely used ECD management app, supporting more than 4,000 centres and 25 partner organisations. However, getting here has been a journey filled with challenges and successes that have offered valuable lessons along the way.

Lesson 1: Purpose and lived experience come before code

In purpose-driven work, success isn't measured by whether the technology functions, but by whether it truly improves outcomes. Before writing a single line of code, it's essential to understand the real challenges faced by those working in the sector. Lived experience must come before technology. Coding should be the last step, not the first.

The takeaway: Invest time validating the problem with the people who live it daily. Build only what directly supports their needs and outcomes. Everything else can wait.

Lesson 2: Plan thoroughly from day one (go slow to go fast)

Skipping proper groundwork leads to costly mistakes later. Before we touched code, we carefully documented how things were already being done and designed for future scale. We created paper flows, step-by-step process maps, and simple mock-ups to capture the "as-is" system in detail. From the beginning, we also anticipated the growth and complexity of wider adoption.

If you don't document your current 'as is' system, you risk getting an incorrect quote. Every tweak post-development costs money. Similarly, retrofitting an app to handle growth is costly and disruptive.

The takeaway: Map out exactly how the current process works and design scalable architecture upfront. Going slow at the start saves time and resources in the long run.

Lesson 3: Choose the right development partner model

Building an app isn't a one-off transaction. You're not just buying a product, you're investing in a long-term capability that will need to evolve and grow with your organisation. One of the most important early decisions is whether you want a vendor who will simply build and hand over the app, or a strategic partner who will stay engaged beyond launch.

The takeaway: Be clear about the kind of partnership you need from the start. If your mission depends on the technology, a long-term technical partner can provide the continuity and expertise required to keep improving over time.

Lesson 4: Structure partnerships with clear accountability

In mission-driven work, budget overruns often lead to mission drift. We avoided this risk by using fixed-price, fixed-scope contracts with milestone-based payments. We refused to pay by the hour. We paid only upon delivery of pre-agreed outcomes. Never pay for incomplete or unsatisfactory work.

Agile methodologies offer flexibility, but timelines and budgets can quickly spiral out of control without strict scope management. We found that Agile only works when milestones, acceptance criteria, and responsibilities are clearly defined.

The takeaway: Link payments directly to results, not time spent. Always pair flexibility with accountability through clear milestones, ownership, and success criteria.

Lesson 5: Own the product internally

Without a dedicated internal product owner, decisions stall and critical context gets lost. Even with a strong development partner, you still need someone inside your organisation who manages the project daily—someone empowered to make decisions, maintain continuity, and stay deeply immersed in the work.

The takeaway: Assign an internal champion to drive day-to-day decisions, coordinate with the development team, and ensure the product always stays aligned with organisational goals.

Lesson 6: Plan for user adoption throughout the journey

Launching the app was only the beginning. The real challenge came afterwards: rolling it out through training, user support, and ongoing activation. Successful implementation requires more than just good code. It demands a dedicated budget, staff capacity, and continuous engagement with users.

We engaged end-users from the very beginning, observing them in real contexts and gathering their feedback to improve usability. But we also recognised that feedback should refine the roadmap, not dictate it. As the product team, we had to guide decisions to keep the app aligned with our mission.

The takeaway: Plan for the post-launch phase as carefully as the build. Allocate resources for training and support, but remember to lead with your vision while listening closely to user experiences.

Lesson 7: Be ruthless about scope

Adding too many features ("feature creep") drains usability, budget, and long-term support. We focused on building only the core functionality that most users truly needed. Like Excel, most users only use 20% of features. Focus on what most people need first. Bells and whistles can come later.

The takeaway: Resist the temptation to build everything at once. Prioritise the essentials that deliver the biggest impact for the majority of users.

Lesson 8: Specify reporting before you collect data

Data you can't access or analyse is a liability, not an asset. By defining reporting requirements upfront, we ensured the app would generate actionable insights from day one. Knowing the reports you need before designing the database strengthens decision-making and makes it possible to measure impact effectively.

The takeaway: Don't collect data blindly. Plan your reporting first so every piece of information captured serves a purpose and helps drive better outcomes.

Lesson 9: Validate the business model (especially in low-income markets)

Good intentions don't automatically translate into sustainable funding. Even for mission-driven products, it's essential to test the business model before scaling. Sustainable delivery depends on understanding who will pay, how they will pay, and when. There might be a gap in the market, but is there a market in the gap?

The takeaway: Don't assume demand equals financial viability. Test and validate the funding model early to ensure your solution can survive and grow while delivering real impact.

Lesson 10: Establish guardrails that keep you purpose-aligned

Without clear guardrails, even well-intentioned projects can drift away from their mission. We established measures to keep every decision and feature focused on real impact. Every feature was tied to a KPI in our Theory of Change, ensuring outcomes mattered more than vanity metrics. We carefully considered the needs of owners, teachers, and partners separately, creating value for each group.

The takeaway: Purpose-driven technology succeeds when guided by clear principles, meaningful metrics, and accountability structures. These guardrails ensure development stays aligned with real-world outcomes.

Building tech for impact isn't easier than commercial software; it just clarifies trade-offs. For ECD organisations and EdTech teams, the key is intentionality: define your Theory of Change, link features to outcomes, document current processes, choose the right partner, and set clear contracts and milestones. Plan for scale, focus on core features, lock reporting specs, and budget for implementation and support.

Go slow to go fast. With precision and purpose, technology can truly serve your mission and deliver lasting change.

---
‍
‍Note: This blog is part of Injini’s contributor series. The views and opinions expressed in this piece are those of the author and do not necessarily reflect the views of Injini.

‍