1:1 mentorship · 15+ years' experience

High school students can code.
We teach them to build properly.

Professional software engineers — 15 years of experience each, minimum — mentoring high school students who are building real web and mobile apps. They write every line of the code. We make sure it's engineered properly.

Book a free 30-min consultation See what students build

Thirty minutes with a senior engineer. We'll look at the goal, look at what's been built so far, and tell you honestly whether we can help.

Students build it. We make sure it's built right. Written authorship and AI-use policy — read how we work

architecture / task-tracker · week-05

FIG. 01 The plan for a student's app, drawn before it was built. Stage 5 of 10, third revision. Reference project, illustrative.

At a glance — what your family gets

01Mentors with 15+ years building software professionally15+ yrs

02First consultation with parent and student, free of charge30 min

03One-to-one sessions, once or twice a week, plus written review betweenScoped to fit

04What high school students finish withA live app

05How much of the code they write themselvesAll of it

The gap

Every applicant has a GitHub link. Almost none can defend it.

A working app proves less than it looks like it does. In our view the thing that separates one GitHub link from another is harder to fake: a student who made real engineering decisions, and who can still explain why months later, under questioning.

How most student projects get built

How professional software gets built

Start writing code immediately

Start by defining the problem, the user, and what it won't do

Follow a tutorial to the end

Choose the technology deliberately, and justify the choice

"It uses React and Firebase"

A written plan for how the app's information is organized, and why

Parts invented as they go

A written agreement for how the parts work together, settled first

Security is "we'll add login later"

Security designed in — who can do what, and where passwords are kept

"It's slow but it works"

Measured, then made faster — with proof of the improvement

Runs on the student's laptop

Running on professional cloud hosting, checked before every change

One giant final_v3 upload

A step-by-step record of every change, reviewed and explained

AI-written code pasted in and hoped for

AI used to go faster, with every line read and understood

Can't answer "why did you do it that way?"

Can defend every decision, including the ones they rejected

The goal isn't a better-looking project. It's someone who can be asked a hard question and answer it.

What we teach

Four stages. The way software actually gets built.

Four distinct disciplines, each done properly rather than skipped — because skipping them is what makes student projects fall over.

01Define

Problem & product thinking

In plain termsMost students start by writing code. We start by making sure they're solving a real problem, for a real person, with the right tools for the job.

Framing a real problem and identifying the actual user
Deciding what's in, what's out, and what the project deliberately won't do
Writing down what the software has to do, in a form that survives being built
Choosing the right technology for this problem — and being able to say why, rather than "it's what the tutorial used"

Student producesA project plan, a requirements list, and a written reason for the technology choice

02Design

Architecture & database design

In plain termsDrawing the plans before pouring the concrete. Skipping this is the most common reason a project has to be rebuilt from scratch at the worst possible moment — right before the deadline.

System design — what the pieces are, how they fit, and what happens when one breaks
Database design — a map of how the app's information is organized, so it can grow without falling over
API design — a written agreement for how the parts talk to each other, settled before anything is built
Security — who's allowed to do what, keeping passwords out of the code, and how someone would attack it

Student producesA system diagram, a data map, a written specification, and records of every major decision

03Build

Application development

In plain termsHigh school students write the software. Each week a senior engineer reads what they wrote, line by line, and shows them how to make it better — the same review a professional gets at work.

Backend & web services — the engine: the part that stores data, applies the rules, and does the work nobody sees
Database work — asking the database questions efficiently, and changing it safely once there's real data in it
Web front end — the screens people use, and how they talk to the engine
Mobile apps, iOS and Android — app structure, what happens when the phone loses signal, permissions, and app store review
Code quality — writing software other people can read, change, and trust

Student producesA working web service and/or mobile app, plus a review history showing how the code got better

04Ship

Cloud, delivery & operations

In plain termsGetting the software off a laptop and onto the internet, where a competition judge or an admissions reader can actually open it — and keeping it running.

Cloud hosting on Amazon or Google — the platforms real companies run on
Keeping a safe practice copy separate from the live one, so mistakes never reach real users
Automatic checks before every change — broken code is refused entry, not discovered later
Testing — what's worth testing, what isn't, and what "it's tested" actually means
Making it fast — measuring what's slow instead of guessing, then proving the improvement

Student producesA live app anyone can open, automatic checks, a test suite, and a measured before-and-after

▚ Across all four

AI & modern practice

In plain termsProfessional engineers use AI tools every day. We teach high school students to use them the way a professional does — as an accelerator they check, not an author they trust.

Adding AI features to an app: choosing a model, judging whether its answers are good, and what it costs to run
Knowing when AI is the right tool for a problem — and when it emphatically isn't
AI-assisted development, done responsibly — using AI coding tools to go faster, then reviewing, understanding, and being able to defend every line
Why "it works" is not the same as "it's correct"

Student producesAn AI-assisted feature they can explain line by line, plus a written record of where AI was used — governed by our AI-use policy

What happens after the consultation

The consultation is where we work out whether the project is one we can genuinely help with — and we will say so if it isn't, including when it needs depth we don't have. If it is a fit, you get a written scope and a quote, and the work starts from the stage your student is actually at rather than from stage one by default.

Student work · figures 02–06

This is what students actually produce.

Real deliverables from real engagements. High school students wrote the code; these are the documents that show how they thought.

If you're a parent, read this first This section is deliberately technical — it's the evidence, and it's the part high school students care about most. You don't need to understand the diagrams. What matters is that a project produces documents like these at all: almost no school project does. Every figure has a caption in plain English.

docs/data-model · revision 3

FIG. 02 A map of how the app's information is organized. This is the third version. In the first, the student had allowed a task to have several owners at once, which would have caused confusing bugs months later. Finding it took one 20-minute review — before any code depended on it. Reference project, illustrative.

openapi.yaml → the readable version

Written first — the specification

openapi: 3.1.0
info:
  title: Task Tracker API
  version: 1.2.0

paths:
  /v1/projects/{id}/tasks:
    get:
      summary: List tasks in a project
      parameters:
        - name: cursor
          in: query
        - name: limit
          schema:
            type: integer
            maximum: 100
            default: 25
      responses:
        '200': a page of tasks
        '404': no such project
# error format decided at stage 4,
# written down as decision 004

The readable version

GET/v1/projects/{id}/tasksa page at a time

POST/v1/projects/{id}/taskscreate

GET/v1/tasks/{id}cached

PATCH/v1/tasks/{id}partial update

DEL/v1/tasks/{id}recoverable

GET/v1/projects/{id}/reviews—

POST/v1/auth/tokenrate limited

NoteEvery address, every result and every error was agreed and reviewed before a single one was built.

FIG. 03 A written agreement for how the parts of the app talk to each other. A high school student wrote this before building anything — deciding the rules first, then following them. Professional teams work this way. Almost no school project does. Reference project, illustrative.

change #47 · faster task list · 4 comments

src/services/tasks.ts

async function listTasks(projectId, cursor, limit) {

- const all = await db.task.findMany({ where: { projectId } })

- return all.slice(cursor, cursor + limit)

+ return db.task.findMany({

+ where: { projectId, ...(cursor && { id: { gt: cursor } }) },

+ orderBy: { id: 'asc' },

+ take: Math.min(limit, 100),

+ })

}

M

Mentor mentor 4 days ago

The old version loaded every task in the project into memory and then took a slice. With 40 tasks you'd never notice. At 40,000 the app falls over. Before you change anything — what do you think that slice actually costs, and who pays for it?

M

Mentor mentor 4 days ago

Your own specification says the largest page is 100. This code quietly reduces a bigger request instead of refusing it. Make the code and the specification agree.

S

Student student · author 4 days ago

Agreed on the validation — moving it. But I want to keep sorting by id rather than by due date like you suggested last week. Due dates can be empty, so pages would come out inconsistent and a task could appear twice. id always increases and is never empty, so the position stays stable. If we need due-date ordering I'd rather add an index on both columns and use both as the position.

↳ Mentor agreed — the student was right

M

Mentor mentor approved 3 days ago

That's right, and it's a better answer than mine — I'd missed that due dates can be empty. Ship it. Write the index idea up as decision 006 so the reasoning survives.

FIG. 04 This is what a mentoring session actually produces. The mentor asks questions and points out problems; the high school student fixes them. In the third comment they disagree with the mentor — and are right. That exchange is the point of the whole program, and it's also a permanent, readable record of who did the work. Names redacted, published with parental consent.

student build · iOS + Android · and the service behind it

iOS

Android

The part nobody sees

No signalchanges are saved on the phone and sent when it reconnects

Staying in synconly fetches what actually changed

Staying logged incredentials in the phone's secure storage, never in the app

Permissionsasked for when they're needed, not at launch

Shared enginethe same service powers the app and the website

App storeprivacy details, age rating, screenshots, review notes

FIG. 05 The app is the part people see. The engineering is behind it. Anyone can put screens on a phone. What distinguishes a serious project is what happens when the phone loses signal, how the login stays secure, and whether one engine serves both the app and the website. Screens redacted, reference project, illustrative.

automatic checks · run #212

Style12s✓ passed

Tests48s · 96 checks✓ passed

Full run1m 34s · 21 checks✓ passed

Database6s · practice copy✓ updated

Live2m 11s✓ deployed

The gate — nothing broken gets in

on:
  pull_request: { branches: [main] }

jobs:
  verify:
    steps:
      - run: npm run lint
      - run: npm test
      - run: npm run test:integration
# no green checks, no merge.
# set up by the student at stage 7.

Making it fast — stage 9

Before1,840 ms to load the task list

Causeone query per row instead of one for all of them

Fixa single combined query, plus an index

After96 ms — 19× faster

Whothe student measured it, found it, fixed it, and proved it

FIG. 06 The app is live on the internet, and it's fast. Every change runs through automatic checks before it's allowed in. On the right, the student found why one screen took nearly two seconds and got it under a tenth of a second — and can explain exactly how. Account details removed.

Authorship protocol · policy v1.0

Students build it. We make sure it's built right.

We're asked about this in every consultation, so we put it in writing and signed it. There are two questions to answer now — who wrote it, and what wrote it.

A mentor does

Ask questions that expose a design flaw
Review code they have already written
Draw the options and explain the trade-offs
Point to documentation and prior work
Require them to defend every decision
Verify authorship through the change history and live defense

A mentor never does

Tell them what to type
Write, paste, or dictate code into their project
Hand over a finished design to copy
Complete homework, coursework, or graded work
Write competition entries, essays, or applications
Ghostwrite anything carrying the student's name

How authorship is enforced, not just promised

All code lives in the high school student's own account. Mentors can read and comment. They cannot write to it.
Every change is recorded under their name — a permanent, timestamped record of who did what, and when.
Review happens in writing. A parent, a counselor, or a competition judge can read exactly what guidance was given.
Weekly live defense. They explain their own code back to the mentor. You cannot defend code you don't understand.
We will state our role in writing. On request we provide a signed letter describing exactly what was and wasn't provided — suitable for a school or a competition.

Part two · the AI-use policy

“You must be able to explain and defend every line in your project — regardless of how it was written.”

Professional engineers use AI tools. We teach students to use them the way professionals do, which is not the way most students use them. That standard above is the whole policy — the rest is how it's applied.

What we teach

Use AI to speed up work you already understand.
Read every generated line. If you can't explain what it does, it doesn't go in.
Never let AI make a design decision unexamined. It is confident about things it hasn't thought through.
Check generated code the way you'd check a stranger's work — because that's what it is.
Keep a record of where AI was used. Professional teams are moving toward disclosure; build the habit now.

What we don't allow

Submitting code they can't explain — from any source: AI, the internet, a friend, or us.
Using AI to produce a project they didn't design and don't understand.
Ignoring the AI rules of the competition or school they're submitting to.

On competitions and schools

Rules differ and they change. We teach students to find the rules that apply to them, read them, and comply — including telling the judges when AI was used.
We will never advise anyone to hide AI use.

The check is the same either way. The weekly live defense applies to AI-assisted code exactly as it applies to hand-written code. A high school student who can walk a senior engineer through every line, explain the trade-offs, and answer "why did you do it this way?" has met the standard — and it's the same bar they'll face in a judging round or a job interview.

student's account→ student's changes→ written review→ live defense→ signed letter

Parents

Attend any session, any time, without asking
Read every review at any time
Sessions are never recorded — our data policy is in writing

Conduct

Signed conduct and confidentiality agreement
Bound by this protocol in writing
No private, off-platform contact with a student

Ownership

High school students own all their code, unconditionally
Project ideas held in confidence
Parental consent required before enrolment

The program

Ten stages. Ten pieces of work. One system they can defend.

One or two 60-minute sessions a week — design and code review — plus written review in between. Stages 1–8 are the professional backbone. Stage 9 is chosen to fit the project.

Not every student needs all ten. A student arriving with a project already half-built does not start at stage one, and a project with no database does not need the database stage. We work out which stages apply at the free consultation and put it in writing before anything starts.

How long it takes depends on the project. A tight, well-scoped build moves faster than an ambitious one, and we would rather finish the work properly than stop at a date.

Phase 1 · Define

Stage 01Problem & scopeWho is this for, what problem does it solve, and what will it deliberately not do?A one-page project plan

Stage 02Requirements & toolsWriting down what the software must do, and choosing the technology to build it with.A requirements list + a written reason for the choice

Stage 03Database designOrganizing the app's information so it stays correct and fast as it grows.A data map + the first working database

Phase 2 · Design

Stage 04The specificationAgreeing the rules for how the app's parts talk to each other — before building them.A written specification the code has to follow

Stage 05System architectureDesigning the whole system, including what happens when a part of it fails.A system diagram + three written records of the big decisions

Phase 3 · Build & harden

Stage 06SecurityWho's allowed to do what, keeping passwords safe, and how someone would attack it.A written threat assessment + passwords removed from the code

Stage 07Going livePutting it on the internet properly, with automatic checks before every change.A working web address anyone can visit

Stage 08Testing & monitoringProving it works, and being able to see what it's doing once real people use it.Automatic tests + a dashboard showing the app's health

Phase 4 · Specialize & defend

Stage 09 Choose one One deeper track, matched to the project. AI / machine learningMaking it fastMobile depthHandling data One deeper piece of work, measured and written up

Stage 10Write up & defendWriting it all up, and rehearsing until every choice can be explained and defended out loud.A written account + a practiced 5-minute defense + everything a competition needs

The same ten stages apply whether the project is a website, a mobile app, or both — a real app needs both sides, and we teach both.

What high school students walk away with

A professional-quality codebase, in their own account
A working app anyone can open, on Amazon or Google's cloud
The design documents behind it

A complete record of every review, proving they did the work
A written account of how they built it, and why
The ability to explain and defend all of it

Competitions

These competitions ask for working software. That's the part we build.

We are not competition coaches. We have never judged these events and we claim no track record in them. Everything below is taken from each competition's own published rules — linked, so you can check it yourself, and you should check again before entering because the details change every cycle. What we do is the software.

Congressional App Challenge

Annual · free to enter · individuals or teams of up to four · 2026 entries close 26 October

What the published rules ask for: Three criteria, the same in every district: "quality of the idea, including creativity and originality; implementation of the idea, including user experience and design; and demonstrated excellence of coding and programming skills." Judges also watch a demonstration video of the app. Official rules →
The part we do: Two of those three criteria are engineering. We work on the implementation and the code — that it runs reliably for someone who is not the student, and that the student can account for how it was built.

Check this competition's AI rules — we'll help high school students comply.

Conrad Challenge

Teams of 2–5, ages 13–18 · adult coach required · Innovation Stage costs $499 per team

What the published rules ask for: Three phases — Activation, Innovation, and the Innovation Summit. The Innovation Stage asks for a written brief answering ten set questions, a 3–5 minute video demonstrating the innovation, and a website describing the team and its intended impact. Cyber Technology & Security is one of the five categories. Official rules →
The part we do: If the innovation is software, we help the student build the thing that the brief and the video have to describe — along with the written record of why it was built that way.

Check this competition's AI rules — we'll help high school students comply.

Technovation Girls

Teams of 1–5, open to students who identify as female, trans, nonbinary or gender nonconforming · division set by the oldest member: Junior 13–15, Senior 16–18

What the published rules ask for: App source code, a pitch video, and a technical video of three minutes or less showing "a demonstration of your project, including showing what works" and "who your users are and how you tested your app with them." Senior teams add a business canvas, Junior teams a user adoption plan. Scored 1–5 per line: 80 points for Senior, 60 for Junior. Official guidelines →
The part we do: The working app and the user testing behind it. "Showing what works" is a build problem, and a clickable mock-up does not survive it.

Check this competition's AI rules — we'll help high school students comply.

Science & engineering fairs

Society-affiliated regional fairs feed Regeneron ISEF

What the published rules ask for: The ISEF engineering criteria total 100 points: a practical need or problem 10, design and methodology 15, execution 20, creativity and potential impact 20, and presentation 35 — of which 25 points is the judge interview. Engineering projects are expected to show a prototype that demonstrates the intended design, tested across multiple conditions and trials. Official criteria →
The part we do: The prototype and the evidence behind it — a measurable before-and-after that someone else could reproduce, and a student who holds up across 25 points' worth of questioning.

Check this competition's AI rules — we'll help high school students comply.

Not entering a competition?

The same work becomes the technical portfolio behind a university application: depth rather than volume, decisions they can defend, and a written record proving they did it themselves. We build the engineering evidence — we don't advise on applications, essays or activity lists.

Working toward a different competition, a hackathon, or no competition at all? Mention it on the call — the approach doesn't change. Donkey Build is not affiliated with any competition listed and claims no endorsement. We describe what the program prepares high school students to produce — not an outcome.

Who teaches

Mentoring by an engineer with 15+ years of professional experience.

That is the floor, not the average. A high school student here is taught by someone who has built and maintained real systems in production — not by a recent graduate or a part-time tutor.

Experience floor15+ years of professional practice, no exceptions

CurrencyWorking in the industry now, or recently enough to teach how it is built today

MethodReview-driven — the student writes it, the engineer questions it

AccountabilityEvery review is in writing, where a parent can read it

The program covers these areas.

Backend & web services

The engine behind the app: server-side structure, business logic, the connections to everything else.

Databases

Designing how information is organized so it can grow, and making it fast when it isn't.

Cloud & infrastructure

Amazon and Google cloud, automatic testing before every change, deployment, monitoring, cost.

Mobile — iOS & Android

Built the way each platform is meant to be built — Swift for iPhone, Kotlin for Android. App structure, what happens when the network drops, permissions, getting through store review.

AI & machine learning

Adding AI features to a real product, judging whether they work, and what they cost to run.

Security & performance

Logins, secrets, and finding what's slow — treated as part of building the thing, not an audit bolted on at the end.

The standard every review works to

One bar, every time. These are the things a review actually checks for.

Whether the error handling was written at the same time as the working path, rather than bolted on afterwards.
Whether they can redeploy their own app from scratch, without notes.
What the app does when the network drops — most student apps break the moment it does.
Whether they went looking for where their own work is wrong before anyone asked them to.
Whether the code and the written specification still agree with each other.
Whether they can say why they rejected the approach they didn't take.

Fit

This isn't right for every student. Here's how to tell.

A good fit

Grades 9–12, and writes code independently in at least one language
Has finished at least one project end to end, however rough
Has five to eight hours a week to build between sessions
Wants to be told what's wrong with their work — and will act on it
Building a website or a mobile app, or aiming at a competition or a CS program

Not a fit

Hasn't learned to program yet — we'll point you to the right starting place
Wants someone to build, fix, or finish the project for them
Needs help with graded homework or coursework
Can't commit build hours between sessions — the sessions only work if there's new work to review
Looking for an admissions consultant — we do engineering, not applications

Not sure? Book the consultation anyway. If we're not the right fit we'll say so in the first five minutes, and point you somewhere better.

Engagement

How it works, practically.

Format

One-to-one only — never group sessions
One or two live sessions a week, 60 minutes each
Written code review in between, on the high school student's own account
Online, scheduled around school and your time zone
Parents may attend any session; nothing is recorded

Structure

Ten stages in the method — not every student needs all ten
We agree which stages apply, and the length, after the consultation, in writing
Shorter deadline sprints for projects already underway
Stage 9 is chosen to fit the project
Scope confirmed in writing before anything begins

Commitments

The same mentor across the whole program
Written review back within 24 hours on weekdays
Signed scope letter available on request
High school students own all their code — always, unconditionally

On cost

We don't publish a price list, because engagements differ — a student sprinting to a competition deadline and a student starting from an idea need different things. We'll quote a specific scope and fee after the consultation, in writing, with no obligation. If budget is a constraint, say so on the call and we'll be straightforward about whether we can work within it.

Questions

What parents ask us first.

Authorship & AI

Is this allowed? Could it count as cheating?

Mentoring isn't prohibited anywhere we know of — ghostwriting is. The difference is authorship, and we make it checkable rather than asking you to take our word: the code lives in the high school student's own account, every change is recorded under their name, all guidance is written down where anyone can read it, and they defend their own code every week. We never touch graded schoolwork, and on request we'll state our exact role in writing.

You teach AI coding — how is that consistent with "they write every line"?

Because the standard isn't who typed it, it's who understands it: high school students must be able to explain and defend every line, regardless of how it was written. That's the professional bar now, and it's the bar in a judging round. They call it "vibe coding" when AI writes something they never thought through — that's exactly the habit we train out. Read the full AI-use policy.

What if our competition or school has its own AI rules?

They differ, and they change. We teach high school students to find the rules that apply to them, read them, and comply — including telling the judges when AI was used. We will never advise anyone to hide it.

Fit & scope

My student already codes well — what's left to learn?

Almost everything that isn't syntax. Scoping a problem, designing information so it won't need rebuilding, agreeing the rules before writing code, thinking about security, deploying safely, finding why something is slow, and defending a decision under questioning. Coding well is the entry requirement for this program, not the subject of it.

What languages and platforms do you cover?

Mainstream backend languages and frameworks, databases, websites, iOS and Android, plus Amazon and Google cloud. Tell us the setup on the call — if none of our mentors has real professional depth in it, we'll say so rather than improvise.

Websites and mobile apps both? Which platforms?

Both. A real mobile app has an engine behind it, so the same ten stages apply either way. On phones we build native — Swift for iPhone, Kotlin for Android — rather than one codebase pushed to both stores. Stage 9 is where we go deep on the phone-specific parts.

How much time does my student need each week?

Five to eight hours of building, on top of the session time itself. The sessions review real work — without new work there's nothing to review and the program doesn't function.

Practicalities

Why aren't there names or photos on this page?

Because a grid of faces tells you nothing you can check. You are told who will be teaching your student — by name, and with their background — on the consultation call, before you have paid anything, and thirty minutes of technical conversation is a far better credential check than a headshot. If you are not confident in the person after meeting them, don't book: the consultation is free and you keep the written summary either way.

How much does it cost?

It depends on scope, so we quote after the consultation — in writing, with no obligation. Bring your budget to the call and we'll be direct with you.

How are mentors matched, and can we change?

We match on the project after the consultation. If the fit is wrong, tell us and we'll change it — a mismatch is our problem to fix, not something a high school student should have to endure.

Do parents attend? Are sessions recorded?

Parents are welcome at any session, always, and you never need to ask first. We don't record sessions — a recording of a minor is a file that has to be stored, secured and eventually deleted, and we'd rather not create it. What you get instead is better: every review is written down, and you can read all of it at any time.

Is my student's idea kept confidential?

Yes. We sign a confidentiality agreement covering student project ideas, which matters when a competition requires original work. We publish nothing about a student's work without written parental consent.

High school students can code.We teach them to build properly.

Every applicant has a GitHub link. Almost none can defend it.

Four stages. The way software actually gets built.

Problem & product thinking

Architecture & database design

Application development

Cloud, delivery & operations

AI & modern practice

What happens after the consultation

This is what students actually produce.

The part nobody sees

Students build it. We make sure it's built right.

A mentor does

A mentor never does

What we teach

What we don't allow

On competitions and schools

Parents

Conduct

Ownership

Ten stages. Ten pieces of work. One system they can defend.

What high school students walk away with

These competitions ask for working software. That's the part we build.

Congressional App Challenge

Conrad Challenge

Technovation Girls

Science & engineering fairs

Not entering a competition?

Mentoring by an engineer with 15+ years of professional experience.

The standard every review works to

This isn't right for every student. Here's how to tell.

A good fit

Not a fit

How it works, practically.

Format

Structure

Commitments

On cost

What parents ask us first.

Thirty minutes with a senior engineer. Free.

High school students can code.
We teach them to build properly.