Technology Platform — Custom vs Off-the-shelf
Debate D05: Technology Platform
Resolution: "Solstice FC should build a custom technology platform for member registration, governance voting, and communication rather than using existing tools (TeamSnap, SportsConnect, etc.)."
Date: 2026-03-09 Format: Lincoln-Douglas Judges: Judge A (Software Engineering Background), Judge B (Nonprofit Operations), Judge C (Youth Sports Administration)
AFF Constructive (Agent: The Architect)
Thank you, judges. I rise in affirmation of the resolution that Solstice FC should build a custom technology platform for member registration, governance voting, and communication.
Let me begin with a simple observation: there is no off-the-shelf tool that does what a cooperative youth soccer club needs. TeamSnap manages rosters and schedules. SportsConnect handles registration and payments. Slack handles messaging. Google Forms handles surveys. But none of them — individually or stitched together — provide cooperative governance infrastructure. And governance infrastructure is not a nice-to-have for Solstice FC. It is the thing that makes Solstice FC what it is.
Contention 1: Cooperative governance requires purpose-built tools.
Solstice FC is not a traditional club with a board that makes decisions and parents who consume services. It is a cooperative where members vote on budgets, elect leadership, approve policy changes, and have fiduciary visibility into finances. This requires:
- Authenticated member voting with verifiable results
- Real-time financial transparency dashboards showing how dues are allocated
- Proposal submission and deliberation workflows
- Scholarship fund tracking visible to the membership
- Meeting minutes, agendas, and decision logs accessible to all members
No combination of TeamSnap + Google Forms + Slack provides this. You would end up with a Frankenstein stack — votes in Google Forms (no authentication, easily gamed), finances in a shared spreadsheet (no audit trail), communication fragmented across Slack, email, and GroupMe. The result is not transparency; it is chaos wearing a transparency costume.
Contention 2: Build-in-public is a strategic asset, not a vanity project.
Solstice FC's build-in-public ethos means the technology itself becomes content. Every design decision, every sprint, every feature ships as a blog post. The platform's GitHub repository becomes a replicable blueprint for other cooperatives. This is not theoretical — platform cooperativism is a growing movement, and there is no open-source template for a cooperative sports organization's digital infrastructure.
The custom platform generates:
- SEO content (technical blog posts about building cooperative tools)
- Community engagement (members can see and contribute to the roadmap)
- Reputational capital (open-source contributors, media coverage)
- Grant eligibility (tech-for-good funders specifically seek open-source civic infrastructure)
Contention 3: The cost argument is outdated.
In 2026, building a web application is not what it was in 2016. With Next.js, Vercel, Neon Postgres, and AI-assisted development, a single developer can ship production software at a pace that would have required a team of five a decade ago. The Solstice FC website already runs on this stack. The marginal cost of adding registration, voting, and financial dashboards to an existing Next.js app is far lower than licensing TeamSnap ($15/team/season), SportsConnect ($3-5/player/season), and Slack Pro ($8.75/user/month) across a growing membership.
Let's do the math. At 200 members:
- TeamSnap: ~$300/year (20 teams)
- SportsConnect: ~$800/year
- Slack Pro: ~$2,100/year (20 active parent organizers)
- Google Workspace: ~$1,440/year (20 users)
- Total: ~$4,640/year, scaling linearly with membership
A custom platform on Vercel's Pro plan ($20/month) plus Neon's free tier is $240/year. Even adding $2,000 in initial development effort (which the build-in-public model turns into content), the breakeven is under 6 months.
Contention 4: Data ownership is a cooperative principle.
The International Cooperative Alliance's principles include democratic member control and autonomy. When your member data lives in TeamSnap's database, you don't control it. When your voting records live in Google Forms, Google controls the audit trail. When your communications live in Slack, Slack controls retention and access. A cooperative that outsources its democratic infrastructure to for-profit platforms has ceded a core governance function to entities with misaligned incentives.
For these reasons, I urge an affirmative ballot.
NEG Cross-Examination
NEG Q1: You cited $4,640/year for the off-the-shelf stack. What is your estimated ongoing maintenance cost for a custom platform — including security patches, dependency updates, bug fixes, and feature requests from members?
AFF A1: With modern tooling, ongoing maintenance is approximately 5-10 hours per month. At a volunteer developer's opportunity cost of $0, the cash outlay is minimal. If we eventually hire a part-time developer, that's a different scale of organization entirely.
NEG Q2: You said "a single developer can ship production software." What happens when that single developer moves away, gets a new job, or burns out? Who maintains the platform?
AFF A2: This is why open-source matters. The codebase is public, documented, and built on mainstream technologies (Next.js, Postgres). Any competent web developer can pick it up. The bus factor is mitigated by the same mechanism that mitigates it for any open-source project — community and documentation.
NEG Q3: TeamSnap has a mobile app that parents already know how to use. Your custom platform does not. How do you handle the UX gap for parents who are not tech-savvy?
AFF A3: A responsive Next.js application works on every phone with a browser. We don't need a native app. And "parents already know TeamSnap" applies to parents who have used TeamSnap — which is a subset, not a universal. The UX bar for a registration form and a voting interface is not high.
NEG Q4: You're a soccer club with zero revenue and zero members. How do you justify spending your founding team's limited volunteer hours building software instead of recruiting families and coaching kids?
AFF A4: The platform IS the recruiting tool. When a prospective family sees a transparent budget dashboard, a functioning democratic voting system, and a public roadmap, they see an organization that is serious about its values. The technology is not separate from the mission — it embodies the mission.
NEG Constructive (Agent: The Pragmatist)
Thank you, judges. I negate the resolution and urge you to reject the seductive but dangerous idea that Solstice FC should build custom software before it has a single player on a field.
Contention 1: You are not a technology company.
Solstice FC exists to provide youth soccer in San Diego through a cooperative model. Every hour spent writing code is an hour not spent recruiting families, training coaches, securing field permits, building relationships with San Diego parks and recreation, or — most importantly — putting balls at kids' feet. The affirmative is proposing that a pre-revenue, pre-member organization should divert its scarcest resource (founder time) into software development.
This is a pattern we see repeatedly in mission-driven organizations: founders who are technologists build technology instead of building the organization. It feels productive because code ships in visible increments. But it is a form of productive procrastination — building the dashboard instead of knocking on doors.
Contention 2: The 90% solution exists today and costs almost nothing.
Let me present the actual minimum viable stack:
- Registration: Google Forms + Google Sheets (free). Yes, really. For your first 50-100 families, a form works perfectly.
- Communication: WhatsApp groups (free). Every parent already has it. No onboarding friction.
- Scheduling: Google Calendar (free). Shared team calendars.
- Governance voting: Loomio (free for small groups, open-source). Purpose-built for cooperative decision-making. Already used by hundreds of cooperatives worldwide.
- Financial transparency: Open Collective (free for open-source/community projects). Provides exactly the transparent financial dashboard the affirmative wants — without writing a single line of code.
Total annual cost: $0.
The affirmative's $4,640/year figure is inflated by including Slack Pro and Google Workspace licenses that no startup club needs. The actual cost of the tools you need in year one is zero dollars.
Contention 3: Custom software creates technical debt before you have organizational equity.
When you build custom, you own every bug. Every security vulnerability. Every browser compatibility issue. Every member who can't log in on their phone. Every password reset email that lands in spam. Every database backup that needs to run. Every SSL certificate that expires.
The affirmative hand-waves this as "5-10 hours per month." In my experience with early-stage organizations, the actual burden is triple that estimate, and it spikes unpredictably — the week before registration opens, the day of a governance vote, the moment a parent discovers they can't access the system.
And who handles this? The same volunteers who are supposed to be coaching U-8s on Saturday mornings.
Contention 4: Build when you have signal, not before.
The lean startup methodology exists for a reason. You do not know what your members need because you do not have members yet. Maybe they want a mobile app. Maybe they want text message notifications. Maybe they hate dashboards and want a monthly PDF newsletter. Maybe they want to vote by show of hands at in-person meetings because they value the communal experience.
Building a custom platform now means building to your assumptions about what a cooperative youth soccer club needs. Building later means building to your members' actual expressed needs, informed by months or years of operating with simple tools and learning what works.
The correct approach:
- Year 1: Free tools. Google Forms, WhatsApp, Loomio, Open Collective. Focus every minute on soccer.
- Year 2: Evaluate. What's breaking? What do members actually request? Where are the genuine gaps?
- Year 3+: Build custom, if and only if the gaps justify it. By then you have revenue, members, and real requirements.
Contention 5: "Build-in-public" can apply to the organization, not just the code.
The affirmative conflates building in public with building software in public. Solstice FC can be radically transparent by publishing its financials on Open Collective, its meeting minutes on a public Notion page, its governance decisions on Loomio, and its stories on its blog. Transparency is a practice, not a technology stack.
For these reasons, I urge a negative ballot.
AFF Cross-Examination
AFF Q1: You recommend Loomio for governance voting. Loomio is itself a custom-built open-source platform created by a cooperative (Enspiral). If their cooperative needed to build custom software for governance, why wouldn't ours?
NEG A1: Because Loomio's cooperative was a technology cooperative — building software was their mission. Solstice FC's mission is youth soccer. Using Loomio is exactly the right move: leveraging the work of a cooperative whose mission aligns with building governance tools so you can focus on your mission.
AFF Q2: You suggest Open Collective for financial transparency. Open Collective charges a 10% host fee on all funds raised. At a $200,000 annual budget, that's $20,000/year. How is that cheaper than building a dashboard?
NEG A2: First, you won't have a $200,000 budget in year one. At $10,000, the fee is $1,000 — still less than the opportunity cost of building custom. Second, you can self-host Open Collective (it's open-source) or switch to a custom solution when the fee becomes material. The point is: don't build before you have scale.
AFF Q3: Your "free tools" stack includes five different platforms (Google Forms, WhatsApp, Google Calendar, Loomio, Open Collective). How do you avoid the fragmentation problem you're supposedly solving?
NEG A3: By accepting that fragmentation is the appropriate state for a pre-revenue organization. Fragmentation across free tools is infinitely better than a single custom platform that is half-built, buggy, and maintained by a burned-out volunteer. You consolidate when you have the resources to consolidate well.
AFF Q4: You say "build when you have signal." But the cooperative governance model IS the signal. We already know we need voting, transparency, and member participation tools. What additional signal are you waiting for?
NEG A4: You know the categories but not the specifications. Do members want async voting or synchronous? Do they want detailed line-item budgets or high-level summaries? Do they want to deliberate online or in person? These are design decisions that should be informed by actual member behavior, not founder assumptions.
AFF Rebuttal
The negation's core argument is "do the simple thing first." I agree with the principle but dispute its application here.
The negation's "free" stack is not free. Loomio's free tier limits you to 50 members and strips key features. Open Collective's 10% host fee scales viciously. WhatsApp groups become unmanageable past 30 parents. Google Forms has no authentication — anyone with the link can vote, and you have no audit trail proving vote integrity. These are not hypothetical problems; they are guaranteed failure modes at modest scale.
The negation asks me to trust that a Frankenstein stack of five different free tools — none designed for cooperative sports governance — will carry us through our most critical growth period. And then, when these tools inevitably break, we should build custom anyway, but now with the additional burden of migrating data from five different platforms into the new system.
The "build later" argument assumes that technical debt only accrues when you build. But duct-taping free tools together creates a different kind of debt: fragmented member data, no single source of truth, lost institutional memory scattered across platforms, and — most damagingly — governance decisions made through tools that can't prove their own integrity.
On the bus factor: the negation is correct that single-developer dependency is a risk. But this risk exists regardless — if the one person who manages the Google Forms and WhatsApp groups and Loomio instance and Open Collective account leaves, you're in the same position, except now the knowledge is spread across five platforms with no documentation.
The platform is not separate from the mission. It is the governance infrastructure of the cooperative. Outsourcing your governance infrastructure to five different for-profit companies is not pragmatism — it is abdication.
NEG Rebuttal
The affirmative makes a compelling philosophical case but ignores the practical reality of early-stage organizations: they die from doing too much, not too little.
Let me address the specific counterpoints. Loomio's free tier limits? Fine — pay for Loomio Pro at $100/year. That's still not "build a custom platform." Open Collective's 10% fee? At your actual year-one budget of $10,000-$20,000, the fee is $1,000-$2,000 — a bargain compared to hundreds of hours of development time. WhatsApp groups past 30 parents? Create channel-based groups (per team, per age group). This is how every youth sports organization in the world communicates.
The affirmative's cost analysis assumes a competent developer donating significant time indefinitely. In my experience with volunteer-driven organizations, this is the single most dangerous assumption you can make. Volunteer developers are the most unreliable resource in nonprofit technology because their professional obligations always take priority. When your voting system goes down the night before a budget approval and your volunteer developer is in a sprint at work, what do you do?
The affirmative frames this as "build the governance infrastructure" versus "outsource to for-profit companies." This is a false dichotomy. Loomio IS a cooperative. Open Collective IS an open-source project. Using tools built by aligned organizations is not abdication — it is solidarity.
Most critically: you have zero members. You have zero revenue. You have zero coaches. You have zero field permits. You have zero teams. Building a custom technology platform right now is building a house before you've surveyed the land. Use simple tools, recruit 50 families, run a season, learn what you actually need, and then build with conviction instead of assumptions.
The resolution asks whether Solstice FC SHOULD build custom. The answer is: yes, eventually. But not now. And "not now" is a negative ballot.
Judge Verdict
Judge A (Software Engineering Background)
Vote: NEG
As an engineer, I'm sympathetic to the affirmative's vision. A purpose-built cooperative governance platform is genuinely compelling, and the build-in-public angle is smart. But the negation correctly identifies the lethal flaw: you're optimizing for a problem you don't yet have, with resources you don't yet possess, for users who don't yet exist. The Loomio + Open Collective stack directly addresses the affirmative's strongest arguments (governance voting, financial transparency) without custom development. Build custom in year 2-3 when you have real usage data. NEG wins on pragmatic sequencing.
Judge B (Nonprofit Operations)
Vote: NEG
In 20 years of nonprofit work, I have watched exactly this pattern destroy early-stage organizations. The founders who are technologists build technology. The founders who are marketers build brands. The founders who are programmers build platforms. And none of them build the actual organization. The negation's year-by-year roadmap (free tools → evaluate → build when justified) is operationally sound. The affirmative's rebuttal about data fragmentation is valid but premature — fragmentation across free tools is a manageable problem for 50 families. A half-built custom platform maintained by a volunteer is an existential risk. NEG wins on organizational focus.
Judge C (Youth Sports Administration)
Vote: NEG
Parents want to register their kid, know when practice is, and see the game schedule. They do not care whether the voting system uses authenticated sessions or Google Forms. The affirmative is building for an idealized cooperative member who deeply engages with governance dashboards. In reality, 80% of your members will never log into any platform except to register and pay. Build the cooperative culture through in-person meetings and community events first. If members demand better digital governance tools — and they might! — build them then. NEG wins because the mission is soccer, not software.
Final Verdict: NEG wins 3-0
Key Takeaways for the Spec:
- Use Loomio (cooperative-built, open-source) for governance voting in year 1
- Use Open Collective or similar for financial transparency in year 1
- Plan for custom platform development in year 2-3, informed by actual member needs
- Document technology requirements as they emerge from real operations
- The build-in-public ethos applies to the organization's story, not just code — blog about governance decisions, community building, and lessons learned regardless of the tools used