Practical guide

A volunteer built our platform, and now nobody can touch it

Someone generous built the platform when the organization was small. Now everything depends on that person. A practical checklist to take back control without starting over.

Felipe SotoJuly 21, 2026 · 5 min read

In 30 seconds

01The code, the data, and the accounts should be in the organization's name, not one person's.
02A good platform is one your own team can adjust, without calling anyone.
03Before building on top, review what already exists. You almost never need to start from scratch.

It's a story we hear a lot, and it almost always starts well. A few years ago, when the organization was much smaller, a volunteer, a friend, or a relative of someone on the team offered to build the platform. They did it with care, often for free, and it worked.

The problem comes later. The organization grows and the platform doesn't. To change a number, some text, or a date, you have to call the developer. During application season, when lots of people log in at once, the system crashes. And one day someone asks where everything is stored, and the answer is: in someone's personal account.

Lately we're seeing a new version of the same thing: platforms built very quickly with AI that work, but that nobody on the team knows how to maintain.

Signs you depend on a single person

You don't need to know anything about technology to notice. If you recognize two or more of these, it's worth taking a look:

To change some text or a simple setting, you have to ask someone outside the organization.
You don't know for sure whose name the domain, the server, or the accounts are under.
There's no user guide, and no document explaining how it was built.
If that person changes jobs or gets sick, nobody else can get in.
At peak times, like application season, the system slows down or crashes.
A previous vendor left the work half done, and nobody really knows what got finished.

The checklist: what your platform should meet

This is the review we do at Sumadots before proposing anything. You can do it yourself, with your team, in an afternoon.

Six points to take back control

1
Everything in the organization's name
The code, the data, and the accounts (domain, server, email, payments) should be in the organization's name. Not the volunteer's, and not the vendor's.
2
More than one key
At least two people on the team should be able to access everything. Keep the logins somewhere safe and shared, not in someone's memory.
3
A guide and a map
A simple guide on how to use it, for the team. And an explanation of how it's built, for whoever comes next.
4
Your team can adjust it
Changing some text, a date, or a number should be something your own team can do, without calling anyone. Otherwise, every tweak becomes a chore.
5
Review before you build
Before adding anything new, look at what already exists and what shape it's in. Building on something you don't understand is building on sand.
6
Ready for peaks
If lots of people apply at once, the platform can process things in batches instead of all at the same time. That way it doesn't crash right when it matters most.

The first point is the most urgent. If tomorrow the person with the passwords doesn't answer, your organization could lose its data. Not out of bad faith, but because nobody thought about it when it all started.

What to do about the person who helped you

This is the delicate part, and the one people ask us about most. Getting the platform in order doesn't mean pushing out the person who built it. It means changing their role.

Before: that person is everything

Designs, builds, and fixes
Is the only one who knows how it works
Every change goes through them
If they're not around, nothing moves

After: that person contributes

Tests new things before they reach the team
Speaks up when something doesn't fit reality
Shares what they know in the guide
No longer carries everything alone

Often, the volunteer who built the first version is the best person to test the next one. They know the history, what failed, and what the team kept asking for. Going from architect to tester isn't a punishment. It takes a weight off their shoulders they should never have carried alone.

The same goes for a previous vendor who didn't finish. Before blaming anyone, review what they left behind. Sometimes there's more progress than it seems, and sometimes you need to rescue the data and start with something simpler.

Where to start tomorrow

You don't have to solve it all this week. Start with what carries the most risk: find out whose name the accounts are under, and make sure at least two people in the organization can get in. With that, you've already stopped depending on a single person.

The rest can come in stages. And if you decide to switch platforms, make it one your team can run without asking anyone's permission.

Felipe Soto