How We Built a Startup Accelerator Platform from Scratch in 12 Months

GrowFast needed to run an accelerator — programs, events, job boards, and payments — without duct-taping together five different tools. They wanted one platform where startups enroll in programs, attendees register for events, candidates apply for jobs, and everything is connected to real payment infrastructure. Stripe for international transactions. Alipay for the Chinese market.

Twelve months, four people, and a greenfield build later, the platform was live. This was our longest and most complex project to date. Here's what we built, what went wrong, and what we'd repeat.

Why they didn't buy

The first question we asked — as we always do — was whether they should build at all. Accelerator management tools exist. Eventbrite handles events. Job boards are commoditized. Payment processors have plug-and-play solutions.

The problem was the connections between these things. A startup enrolled in a program should automatically get access to program events. An event attendee who's also a program participant should see a unified profile. Job applications should be visible to program mentors. Payment reconciliation across Stripe and Alipay needed to land in one dashboard, not two.

No combination of off-the-shelf tools could deliver this without an integration layer that would itself become a custom software project. So we built the whole thing.

The architecture

Laravel was the backbone — handling programs, events, jobs, users, roles, payments, notifications, and the admin dashboard. For a platform this size, Laravel's convention-over-configuration approach was essential. With four developers working in parallel, everyone needed to know where everything lives without asking.

The payment layer was the most architecturally significant piece. Stripe and Alipay have fundamentally different integration models. Stripe uses webhooks with clear event types. Alipay uses server-to-server callbacks with signature verification. We built a unified payment service that abstracts both behind a single interface — the rest of the application doesn't know or care which gateway processed a transaction.

Webhook idempotency was critical. Both gateways can send the same event multiple times. Without idempotency guards, a single payment could be recorded twice — which means wrong revenue numbers, duplicate confirmation emails, and angry finance teams. We implemented deduplication at the webhook handler level using transaction reference hashing.

The hardest problems

Multi-gateway payment reconciliation

Stripe settlements arrive in your bank account as batches, not individual transactions. Alipay has its own settlement cycle with currency conversion. Reconciling "did we actually receive the money for this specific enrollment?" required building a reconciliation engine that matches platform records against gateway reports.

We ran nightly reconciliation jobs that flagged discrepancies automatically. In the first month after launch, this caught three settlement mismatches that would have gone unnoticed without automated checks.

Role-based access across interconnected modules

An accelerator has many user types: program managers, mentors, startup founders, event organizers, job posters, applicants, attendees, and admins. Each sees different data and has different permissions. A mentor can see startup applications but not financial data. An event organizer can manage their event but not others.

We implemented granular RBAC using Laravel Policies, with permissions scoped per module. The admin panel lets GrowFast's team create custom roles without developer involvement — a decision that saved significant time post-launch as their organizational structure evolved.

Email deliverability at scale

An accelerator platform sends a lot of email: enrollment confirmations, event reminders, application notifications, payment receipts, program updates. When you're sending hundreds of emails per day across multiple event types, deliverability becomes a real engineering problem.

We implemented domain authentication (SPF, DKIM, DMARC), email queuing with retry logic, and bounce handling. We also built email templates as configurable objects in the admin — GrowFast's team can edit email content without touching code.

What we delivered

Startup enrollment and monitoring: Programs with application forms, review workflows, acceptance/rejection, and ongoing milestone tracking for enrolled startups.

Events: Creation, ticketing, registration, payment, and attendance tracking. Events can be linked to programs so enrolled startups get priority access.

Jobs: Job posting, applications, candidate management, and integration with the program ecosystem so mentors can recommend candidates.

Payments: Stripe and Alipay with verified webhooks, automated receipts, refund handling, and nightly reconciliation.

Admin dashboard: Operational dashboards for programs, events, jobs, and finances. Custom role management. Analytics and CSV exports.

Notifications: Automated emails and in-app notifications for all key user actions, with configurable templates.

Twelve months: how we structured it

A year-long project needs different discipline than a three-month sprint. Here's how we phased it:

Month 1: Discovery. Stakeholder interviews, requirements baseline, success metrics definition. We didn't write code — we wrote documents. The scoping phase on a project this size is the difference between a controlled build and a runaway budget.

Months 2-3: Scope and contracts. Domain modeling, API contracts, UX flows, and payment path design. We defined every webhook handler, every role permission, and every email trigger before building.

Months 4-10: Build. Core modules first (users, RBAC, programs), then payments, then events and jobs, then notifications and reporting. Bi-weekly demos throughout — our standard process — which caught scope misalignments early.

Month 11: Hardening. Production infrastructure, load testing, security audit, data migration, and DNS cutover preparation.

Month 12: Launch and handover. Go-live, runbooks, team training, and the first round of post-launch iterations based on real usage data.

What we learned

Design payment flows early, with clear fallback paths. We designed the payment architecture in month 2, not month 6. Every payment scenario — success, failure, timeout, duplicate webhook, partial refund — was mapped before we wrote a line of payment code. This saved us from at least three architectural rewrites that would have been necessary if we'd "figured it out as we went."

Use versioned APIs and DTOs for stable integrations. Both Stripe and Alipay update their APIs. We wrapped all external communication in versioned DTOs (Data Transfer Objects) so that an API change on the gateway side requires updating one mapping file, not touching business logic.

Observability and runbooks reduce operational load. We built monitoring and alerting alongside the application, not after. When the platform launched, the operations team had runbooks for every alert — "if you see this, do that." This meant GrowFast's team could handle most issues without calling us.

Keep admin simple; optimize where staff spend time. We initially over-engineered the admin interface with features nobody used. In the second half of the build, we observed which admin tasks GrowFast's team performed most frequently and optimized those flows specifically. The lesson: build admin tools iteratively, not upfront.

Automated tests around billing prevent regressions. Payment code is the most dangerous code to break. We wrote comprehensive test suites for every payment scenario — successful charge, failed charge, refund, webhook replay, currency conversion edge cases. These tests caught three billing regressions during development that would have reached production without them.

The result

GrowFast launched a unified platform covering startup programs, events, jobs, and integrated payments across Stripe and Alipay. Operational dashboards give the team visibility without technical knowledge. Automated reconciliation keeps finances accurate.

The program director described it simply: the platform brought their programs, events, and jobs into one place with smooth payments, and delivery was clear and pragmatic throughout.

For full details, read the complete GrowFast case study.

Planning something this big?

A 12-month, four-person build is a serious investment. If you're considering a platform of this scope, start with a solid brief, understand what drives timelines, and know what to ask before you sign. And make sure you've honestly evaluated whether building is the right call — sometimes it isn't.

Have a platform-scale project in mind? Let's scope it together →

ERP: Buy Odoo, Customize Odoo, or Build from Scratch?

Highlights

Get Started