High School Project Looking for a Coder? What to Try Before Building the App
The Google Doc was titled “Coder search FINAL.” Across the kitchen table, my daughter Lila and her two friends stared at one sentence:
“High school project looking for coder/developer to build student wellness app. Experience with app design preferred. Serious inquiries only.”
It was a Sunday evening. Pasta water was heating on the stove, and the group chat kept pinging with ideas: mood check-ins, meditation timer, counselor referral button, homework calendar, anonymous reporting, resource map. They had a color scheme. They had a logo. They did not have a single screen that worked.
Lila, a sophomore, was in charge of a health-class project about stress during exam season. Her group had decided that posters and surveys were “too basic.” An app felt like the answer. The only problem was that none of them knew how to make one.
I leaned against the counter and asked, “What would the app do after someone taps the mood button?”
“Give them resources,” one friend said.
“Which resources?”
“Like, breathing exercises.”
“Where do those come from?”
They looked at one another. That question had not made it into the slide deck yet.
This is the part I have seen again and again with school projects. Once someone says “app,” the conversation jumps straight to technology. Coding becomes a kind of magic: find a coder, explain the big idea, wait for the finished product. But a developer cannot replace the harder work of deciding who uses something, what happens first, and what problem it actually solves.
I did not want to take over. I also did not want them spending the next week cold-messaging strangers on Discord while the project stalled. So I grabbed a stack of index cards and said, “Before you recruit anyone, draw the first five screens. One card per screen. Show me what a student taps and what happens next.”
For ten minutes they complained that this was not coding. Then they started moving cards around. The mood check-in became three emoji buttons. The counselor referral disappeared because they realized they could not safely manage real messages from students. The homework calendar was cut because it duplicated the school’s existing system. By the end, they had a much smaller idea: a short check-in form, a screen with three school-approved tips, and a page linking to the counseling office.
It was not impressive in the way they had imagined. It was also buildable.
Their post did get one reply: an eighth grader from the coding club who knew Python and wanted experience. He was enthusiastic, but when they mentioned login screens and anonymous messaging, he went quiet. I could see why. They were asking a beginner to take on product design, security, and privacy in exchange for “great for your résumé.”
Lila asked me what they should do.
“Tell him the truth,” I said. “It’s a class project, not a startup. Ask if he can help with one specific piece, and make sure he knows the rest of you will do the content and testing.”
She typed: “We don’t need a whole app anymore. We’re making a prototype with fake data. Could you help us make the buttons connect to the right screens? If not, no worries.”
He said yes. They used a free no-code tool they found through the school library, connected a few pages, and presented a clickable prototype with sample students named Student A, Student B, and Student C. No one’s real mental-health information was collected. No one promised a product the school could actually launch. They got a B+.
Lila was mildly annoyed. I thought the grade was fair.
What stayed with me was how quickly the group had treated “find a coder” as the first step rather than the last. Many high school projects encourage students to think big, which is good, but big thinking often runs ahead of practical planning. A team can spend more energy recruiting someone technical than understanding the problem. The coder then becomes either a magician or a bottleneck. If that person leaves, the project collapses. If they do all the building, the other students learn little about how the piece works.
Since that project, I have noticed a few simple moves that help at home and in class.
The first is to demand a paper prototype before any code. Index cards, whiteboards, even a Google Doc with “Screen 1, Screen 2” works. Ask: What does the user tap? What appears next? Where does the information go? If students cannot explain it on paper, writing code will only make the confusion faster.
The second is to separate data from design. Many school “apps” are really a form, a spreadsheet, and a summary page. A Google Form can collect responses. A spreadsheet can sort them. A simple site or slideshow can display the results. For a class project, that may be enough. The phrase I use now is, “Can we test this with a spreadsheet before we ask anyone to code it?”
The third is to make recruitment specific. A post saying “looking for a coder” attracts either no one or someone willing to overpromise. A better note names the task: “Need help making four buttons link to four pages in a no-code tool. About two hours. School project, beginner-friendly, credit in presentation.” That respects the other student’s time and makes the scope visible.
Teachers can help by making these expectations part of the project. Before groups bring in outside help, they can submit a one-page plan: who is the user, what is the smallest testable version, what tools are being used, and what each group member will do. A short rule can prevent trouble: “Outside tools and helpers are fine, but every group member must be able to explain how information moves through the project.” That keeps students from hiding behind a technical teammate.
Privacy also deserves a direct conversation. If a project involves health, location, grades, or anonymous reporting, students should not collect real data without school approval. Fake sample data is usually enough for a presentation. I learned this when Lila’s group realized their “anonymous” app could still collect email addresses through the form. That was a more useful lesson than any feature they could have built.
I am not saying students should avoid ambitious tools. Lila later messed around with basic HTML on her own because she wanted to understand what the eighth grader had done. She did not suddenly become a developer. She did learn that coding is not one giant skill called “making an app”; it is many small decisions, most of which begin with a clear question.
Her group still talks about rebuilding the wellness project properly. They want logins, real resources, and maybe a dashboard. They also now know those words mean weeks of work, privacy reviews, and someone maintaining the thing after the presentation. That last part is usually missing from high school slide decks.
Last week Lila opened the old prototype, clicked a few buttons, and said, “It looks kind of cheap.”
I asked what she would change first.
She thought for a second. “Probably the first screen. It asks too many questions before it gives anything useful.”
That sounds like progress, even if there is still no app in the app store.
Please indicate: Thinking In Educating » High School Project Looking for a Coder