The problem
The website was older than some of the kids using it.
MedinaCHF is around fifty families — a full calendar of gatherings, dues, applications, the whole rhythm of a real community. The public website had been built on Wix back in 2011. Nobody had touched it professionally since. There was no developer on call, no support contract, nobody to phone when something went sideways.
And things did go sideways. Wix pushes its own updates on its own schedule, and every so often one of them would quietly break something on the site — with no warning and no one responsible for fixing it except the volunteer who ran the community, on top of everything else that job already involved.
The app families actually used to sign up for things wasn't much better. Polls — a simple thing, used constantly — didn't reliably work. Most of what the app offered was generic, built for a different kind of group entirely, so the whole community had learned to work around it instead of with it. People mostly just put up with it, the way you put up with a leaky faucet you've meant to fix for years.
Underneath all of it, the actual business of running the community — applications, dues, who was hosting which event — ran on email, PayPal, and a physical corkboard that only worked if you happened to see it in person.
Its leadership had already talked it through before ForgeKit ever got involved, and landed on the same conclusion most people in their position eventually do once they've tried the shortcuts: buying another off-the-shelf app wasn't going to fix this. They needed something actually built for them — and the honest fear, going in, was that “actually built for us” meant a price tag a volunteer-run community simply couldn't justify.
What actually happened
The first plan wasn't built to survive contact. It was built to be argued with.
The first working plan came together in an afternoon — how the platform would work, what it would ask of families, what its coordinator would see. But instead of starting to build it immediately, that plan got picked apart on purpose: a deliberate, adversarial second look, arguing against the plan specifically to find what could go wrong before a single real family's information was on the line.
Almost everything that review changed made the design more careful, not more ambitious — less data collected than the first draft assumed, tighter defaults on what got shared automatically, a harder look at exactly what an AI feature should and shouldn't be allowed to send without a person reading it first. That's usually a good sign in a first draft: the mistakes were on the side of doing too much, not too little.
1
How this is possible
Assurance happens while the thing is being built, not after.
Most software mistakes get found the expensive way — after launch, when a real user hits them. Here, the plan itself got attacked before a line of code existed, specifically looking for what would go wrong. That's not a one-time step. It's the same posture applied again later in this story, when the reusable version of this platform got handed to an independent review with one job: find what's wrong with it. Building fast doesn't mean skipping this. It's what makes fast safe to do.
Then came the part that mattered most: sitting down with what its leadership had already decided about how the community runs, and turning it into real decisions instead of guesses. Dues at $12 a family, per year. Simple sign-in with no password to forget. A new way to control who could see an RSVP that hadn't existed in any plan until that conversation surfaced it. Even a naming change — what had been called “anchor events” became Signature Events, because that's what it actually felt like once someone said it out loud. None of that comes from a form filled out days later — it comes from someone actually listening in real time.
Why are we planning against a calendar at all, when the whole advantage of building this way is that it removes the cost of changing your mind?
From the build notes, on being asked to defend an aggressive launch date
Asked to prove the platform could be ready in under two weeks, the honest answer — backed by a real look at how fast similar work had gone before — was “probably, if nothing goes wrong.” That answer got rejected, not because it was wrong, but because it was the wrong question. Nobody needs a project plan with dates attached to promises that haven't been tested yet. What mattered was the order things got built in, and the one real deadline that actually existed: dues needed to be collectible before the community's Kickoff Picnic.
Building it
The site went live the same day it was started. That's not the whole story.
Applications, dues tracking, a real member sign-up flow, event RSVPs, and a dashboard for its coordinator to actually see what was going on — all of it went from nothing to a live, working site in a single day.
It wasn't completely smooth. Late that same day, a real problem showed up: the login system MedinaCHF was using has a free tier that caps out at twenty people sharing one account — and this community holds fifty families in one shared space, by design. Fixing it meant changing how the whole app handled accounts. Because of how it had been built — carefully, with that kind of change in mind even before it was needed — the fix touched a handful of files instead of nearly all of them. It shipped the same day, without anyone waiting on it.
That fix also did something better than save time — it removed a cost that would have shown up on every future bill. The login system's paid tier existed to support multiple separate accounts; MedinaCHF only ever needs one. Recognizing that meant the paid tier wasn't something to budget around. It just wasn't needed.
2
How this is possible
Change is cheap by design, not by luck.
An architecture decision that would normally take days to safely unwind got absorbed the same afternoon it was found, because the app was never written to assume any one piece was permanent. That's the same reason that, weeks later, a coordinator could say “don't assume any of this has to stay” about the member-facing side of the app, and the answer could be “then let's rebuild it,” not “that's outside what we agreed to build.”
About a week in, members got the ability to plan their own events — propose one, pick a time, invite people. Before that shipped, a second look flagged a real concern: if a member could mark their own event as fully approved with no review at all, something unofficial could end up looking official. Its leadership heard that concern and made the call anyway — member freedom stayed, on purpose, because that's how the community was meant to feel. What did change: the system now enforces the actual rules around it (an event still in the idea stage can't pretend to have a real date yet), and members can only edit their own events, not anyone else's.
A week after that, a clear instruction came down on the member-facing side of the app: don't assume anything needs to stay the way it is. That led to a real rebuild — not a patch — of how members see their own home screen, their events, their profile. It surfaced two real bugs that had been quietly live the whole time, including one where a query could return the wrong membership year entirely under certain conditions — the kind of thing that stays hidden forever behind an unchanged screen.
About two weeks in, what had been built specifically for MedinaCHF got turned into something reusable — a starting point other communities could use, without touching or risking the live site families actually depend on. Before that reusable version was considered finished, it got handed to a second, independent review with one job: find what was wrong with it. That review caught five real gaps — small things, like a dues amount that looked configured but wasn't actually connected to anything — the kind of mistake that's invisible until a second community hits it for real. All five got fixed before anyone else ever would have found them the hard way.
3
How this is possible
Bespoke doesn't mean starting from zero.
MedinaCHF got software made around MedinaCHF. But underneath it, that work became reusable architecture, decisions, and known failure modes ForgeKit now carries into the next build — the login-model fix, the way member data stays private by default, the pattern for tracking who actually showed up versus who just said they would. The next community like this one doesn't start from a blank page. It starts from everything this one already taught the system.
What it actually costs
The Wix bill was never the real cost.
It's tempting to compare this to the old site by comparing bills. That misses almost everything that actually changed — and it also isn't the comparison most groups in this position are actually making. Here's the fuller picture, priced honestly on all three sides.
A typical DIY builder
$16–30/mo
A standard Wix/Squarespace-type plan for a community site
- —No IT support included — billing and outages only, not your pages or your parent portal
- —The plan that actually accepts online payments runs closer to $30/mo, not $16
- —No one built it around how your group specifically runs — you adapt to the template
- —When something breaks, it's still your problem to notice and fix
Traditional custom-built site
$70–320/mo
Hosting, plus a developer on retainer to keep it running — after a real build cost, paid upfront
- —A real project cost to build it, paid upfront, before it does anything for anyone
- —Ongoing hosting on top — this is not included in the build price
- —A maintenance retainer for updates and fixes runs $50–300/mo on its own, same as a builder site's support
- —Fits the organization well — but the upfront cost is what makes it out of reach for most volunteer-run groups
MedinaCHF, built by ForgeKit
~$21–22/mo
Everything it takes to run the real platform — itemized, not a guess
- Hosting$20/mo
- DatabaseFree
- Member accountsFree
- EmailFree
- AI features$1–2/mo
Fits like the custom-built option. Costs like the DIY one. Maintained going forward by ForgeKit — no separate support bill, because it's already included.
Notice the middle column's monthly number isn't actually that far from the other two — hosting is hosting, and a support retainer is a real, fairly normal cost either way. The thing that actually keeps most volunteer-run groups out of the middle column isn't the ongoing bill. It's the real project cost to build it in the first place, paid upfront, before it does anything for anyone — a cost most community organizations never even get a quote for, because they've already assumed it's out of reach.
The third column is what changes when that upfront cost drops, because the software gets built at AI-era economics instead of traditional-developer economics, by a system built to catch its own mistakes along the way. MedinaCHF isn't cheaper because it does less. It fits the organization the way traditionally custom software would have — without the upfront cost that put that option out of reach to begin with.
What this means for you
You don't have to be a homeschool community for this to apply.
Swap the details and this is the same story a lot of small organizations are living right now: a church small group tracking attendance on a spreadsheet, an alumni association running dues through Venmo screenshots, a hobby club with a Facebook group standing in for a real member directory. The software is old, or missing, or was never actually built for how the group works — and one person ends up carrying the difference, unpaid, indefinitely.
That's the actual thing MedinaCHF proves: not that a website can be built fast, but that it can be built around your organization specifically— your dues structure, your events, your privacy expectations — for close to what a decent group already spends trying to patch something that was never right to begin with. And once it's live, the maintenance, the updates, the “why did this break” calls stop landing on you.
Nothing in how this got built was special-cased for MedinaCHF — the careful first pass, the attention to the decisions that don't show up on a checklist, the honesty about a bug instead of a quiet patch, the discipline to make it reusable without touching what's live. That's just how this gets built, for whoever's next — and every organization ForgeKit builds for makes the next one start a little further ahead.
