No engineering team. Eleven weeks to launch. Live on schedule.

iPark announced a twelve-week programme before a line of software existed. Six hundred applications arrived in the first month. All of them lived in a spreadsheet, an inbox and a shared drive, sorted by hand. The first cohort was fourteen weeks out and the date was public.

Everything the programme promised was manual. Application scoring, diligence collection, mentor matching, milestone tracking, grant disbursement — two programme managers spent their days copying rows between documents, and the cohort had not even started.

Building an engineering team from zero, in a market where senior developers are scarce and slow to move, would have taken longer than the runway to the first cohort. So iPark borrowed a team instead of building one. We matched the first developer in three days and five inside two weeks, with a single mandate: production before cohort one.

What five developers built in eleven weeks

Scope was set against the date, not the wish list. Anything that did not have to exist for the first cohort was written down and deferred in the open.

Core functions handled by the team:

• Application intake: a structured form, scoring rubric and reviewer queue replacing six hundred rows of spreadsheet.
• Diligence workspace: document collection, checklists and shared reviewer notes, one room per applicant company.
• Mentor matching: operators tagged by sector and stage, matched to founders by the programme manager in minutes instead of days.
• Milestone tracking: each company’s twelve-week plan, with progress visible to both the founder and the programme team.
• Disbursement tracking: grant schedules, milestone gates and payment status, visible to both sides of the agreement.

“We told them the date and they built backwards from it. Nobody asked for an extension, which in my experience is the rarest thing in software.” Rana Odeh, Programme Director, iPark

Why byThursday.ai instead of hiring in-house

iPark never intended to become a software organisation. It needed a platform to run a programme, built once, properly, by people who would then hand it over.

• A team on day three, not month three — with eleven weeks to build, hiring was arithmetically impossible before the deadline.
• Product judgment, not just execution — the team cut two features in week four that would have missed the date, and said so early enough for it to help.
• No permanent headcount — iPark runs a lean programme team. Carrying five engineers between cohorts was never the plan.

“We came out of it with a working platform and a team that understands it. That second part is what I had been warned we would lose.” Rana Odeh, Programme Director, iPark

How a deadline build stays on the date

The five steps behind every byThursday.ai engagement matter most when the date cannot move. On a fixed-date build they are what turn a deadline into a scoping tool rather than a crisis.

The five pillars:

1. Vetting before the match: a live full stack build and an AI-tooling assessment, filtered for developers who had shipped greenfield products against a fixed date.
2. Scoped to the stack: Next.js, TypeScript and Postgres, chosen in week one for what iPark’s eventual in-house engineer would be able to maintain alone.
3. Written handover: every module documented as it shipped, so the platform could be handed over at the end rather than explained in a meeting.
4. Weekly checkpoints: scope reviewed against the launch date every week. Two features were cut, both in writing, both early.
5. Replace, don’t renegotiate: the guarantee holds on a fixed-date build too — one swap in week two, replacement shipping within five business days.

On a deadline build the checkpoint is not a status meeting. It is where scope gets cut while cutting it still helps.

What iPark has run on the platform since launch

The platform went live four days before the first cohort and has carried every cohort since without an engineering hire.

• Live in 11 weeks — four days ahead of the first cohort’s start date.
• 140 startups onboarded — across three cohorts, with no additional engineering headcount.
• $4.2M tracked through the platform — grant schedules and milestone gates handled end to end.
• Programme operations: 2 full-time managers to 0.5 — both moved onto founder coaching instead.

What other teams can take from this

iPark’s build was unusual in its deadline and ordinary in everything else. These are the parts worth copying.

• A fixed date is a scoping tool. iPark shipped because two features were cut in week four, not because anyone worked weekends.
• Borrow the team for the build, own it for the maintenance. Handover documentation written during the work is what makes that possible.
• Choose the boring stack. The platform was built to be maintained by the single engineer iPark would eventually hire.
• Operations debt compounds faster than technical debt. Every week in spreadsheets was another week of data the platform would later have to import.
• Three days versus three months is the story. Nothing else about the engagement would have mattered if the team had arrived in month three.

What’s next

iPark is opening the platform to two partner programmes running their own cohorts on it, which means multi-tenancy and per-programme branding — a scoped engagement with two of the original developers returning for it.

Funder reporting is next after that. The in-house engineer iPark hired last quarter now owns the codebase, working from the same runbooks the matched team wrote while building it.