Case StudyMobile Development

Value Ed : Mobile App -> The next generation of education in the palm of your hand

I built a Flutter app to centralise Value Ed's scattered information. Sessions, events, and programs in one place — no more hunting through WhatsApp groups.

7 min read

Building the Value Ed App: A Lesson in Working With What You Have

I inherited a challenge that will sound familiar to anyone who's worked with growing organisations: scattered information, a lean budget, and ambitions bigger than the resources to match them.

Value Ed serves students and young professionals through educational sessions, events, and programs. They had built something real — a community. They had content people genuinely valued.

What they didn't have was a central place to access any of it.

Information lived in WhatsApp groups. Announcements got buried under memes and good-morning messages. Members had to ask around just to find out when the next session was happening — like trying to find your keys by shouting into every room.

My job was to fix that. Without breaking the bank.

The Vision: One Place for Everything

The brief was straightforward: create a hub. A single place where Value Ed members could find everything they needed.

  • Upcoming sessions and events
  • Information about programs
  • Details about hosts and facilitators
  • Testimonials from past participants
  • Team member profiles

No more hunting through chat threads. No more "when's the next session?" messages floating into the group at random hours. Just open the app. Know what's happening.

Simple in concept. Complicated in execution.

The Constraint That Shaped Everything

Here's the reality of working with growing organisations: there's rarely a big tech budget.

Value Ed needed an app, but they couldn't afford a massive development project with dedicated infrastructure, multiple developers, and ongoing server costs that would bleed them dry.

So every decision had to be strategic. Maximum impact, minimum spend. No feature for feature's sake.

The Decision That Made Everything Possible

Value Ed already had a Wix website. That website already contained most of the information we needed — sessions, hosts, events, programs. It was maintained. Updated. Alive.

The traditional approach would be to build a separate backend for the app. Create a database. Set up APIs. Then maintain two systems with the same data, forever slightly out of sync, forever requiring double the updates.

That's expensive. That's exhausting. And for a lean organisation, that's a recipe for abandonment.

Instead, I built JavaScript backend APIs directly on the Wix platform. The app pulls data from the same source as the website. One update, reflected everywhere. No sync issues. No duplicate maintenance.

Was the Wix documentation frustrating at times? Yes. Did it take some creative problem-solving? Absolutely. But the result was an architecture Value Ed could actually sustain. An app that wouldn't become a burden.

Sometimes the clever solution isn't the elegant one. It's the one that survives.

The Tech Stack: Practical Over Flashy

Every technology choice was made with longevity in mind:

  • **Flutter** — One codebase for both iOS and Android. Half the development time, half the maintenance.
  • **Firebase** — Authentication and push notifications. Reliable, scalable, and free at Value Ed's usage levels.
  • **Wix backend APIs** — Leverage what exists instead of building what's new.
  • **Zoom API** — Members can join sessions directly from the app. One tap from calendar to live room.

I also brought on a UX/UI designer to help shape the screens. Good design matters. Having someone focused on that freed me to concentrate on making the technical architecture sound.

The Experience We Built

When a member opens the app, they land on a calendar view. All upcoming sessions and events, laid out cleanly. At a glance, they know what's happening and when.

Fifteen minutes before any session, a push notification arrives. A gentle tap on the shoulder. *Hey, this is coming up. Don't forget.*

No more forgetting. No more missing out because the WhatsApp message got buried.

When they tap a session, they see details — and a direct link to join the Zoom room. One tap from schedule to live. That kind of friction reduction actually changes behaviour. It turns *I meant to attend* into *I did attend*.

Beyond the calendar, members can explore programs, meet hosts, read testimonials, see the team. Everything in one place. Everything current.

Where I Got Stuck

Two things tested my patience more than I expected:

**Wix Backend APIs**

The documentation wasn't always clear. Building JavaScript APIs on the Wix platform required trial, error, and occasionally staring at cryptic error messages until meaning emerged. But once I cracked the patterns, it worked reliably. The frustration was front-loaded.

**Zoom API Authentication**

Zoom's webhook system requires ongoing reauthentication. It's not a set-and-forget integration — tokens expire, connections need refreshing. Not difficult once you know what to expect. But it caught me off guard at first. One of those "read the documentation more carefully" lessons.

The Reality of the Timeline

The app took about a year to build.

Not because it was technically complex. But because it wasn't the only priority.

Value Ed had urgent issues to address — the app was important but not critical. So development happened in bursts. Sprints between other work. Progress in stolen moments.

That's the reality of being CTO for a growing organisation. You're juggling. Not everything moves at the speed you want. You learn patience, or you burn out.

What Happened After

The feedback warmed me: the team really liked the app. They saw it as a solid foundation — something to build on, not just something to use.

This was always meant to be version one. Proof that the concept worked. Proof that members would actually engage. The plan was to learn from this version and iterate toward something even better.

I no longer have access to download statistics, so I can't quote specific numbers. But the app did what it was built to do: give Value Ed members a central place to engage.

That's enough.

What I Learned as CTO

**Be firm on the goal, flexible on the method.**

There are many ways to build an app. I could have pushed for a "proper" backend with dedicated databases and custom APIs. It would have been more elegant architecturally. Textbook-correct.

But it wouldn't have been right for Value Ed's situation. The Wix integration was unconventional. Some developers might raise eyebrows. But it solved the problem within the constraints we had.

Don't force a specific method because it's the "correct" way. Be open to alternatives that actually fit the context.

**Use what's already there.**

The best technology decisions aren't always about picking the newest or most powerful tools. Sometimes they're about noticing what already exists and building on top of it.

Value Ed had Wix. Value Ed had content. My job wasn't to replace that — it was to extend it into a new channel.

**Cost-effectiveness is a feature.**

For organisations without big tech budgets, sustainability matters more than sophistication. An app that's cheap to maintain will survive. An app that requires constant investment might not.

Firebase, Flutter, Wix APIs — these weren't compromises. They were strategic decisions that gave Value Ed a real product they could actually support.

Why This Belongs in My Portfolio

The Value Ed App showcases something I value about how I work: adaptability.

I didn't walk in with a predetermined stack and force it on the organisation. I assessed what existed, understood the constraints, and built something that made sense for *this specific situation*.

That's what leadership should look like. Not just writing code. Making strategic decisions that serve actual needs.

This project demonstrates my ability to:

  • Work within tight budget constraints
  • Leverage existing platforms creatively
  • Make pragmatic architecture decisions
  • Deliver real products that real users actually use

Sometimes the best solution isn't the most impressive one. It's the one that works. The one that lasts. The one the organisation can grow with.

---

Technical Summary

**Timeline**: ~1 year (alongside other priorities)

**Role**: Chief Technology Officer

**Team**: CTO + UX/UI Designer

**Key Learning**: Be firm on the goal, flexible on the implementation

---

*Looking for strategic technology leadership? [Let's connect.]*

Tags

#Flutter#Firebase#Wix API#Zoom API

Want similar results for your business?

Let's discuss how I can help translate your ideas into solutions that deliver real value.

Get notified of new case studies

Subscribe to receive updates when I publish new project deep-dives and tech insights.

No spam, unsubscribe anytime. Typically 1-2 emails per month.