Teachneat
Teachneat was a web app for secondary school teachers. It kept one class list in a Google Sheet on the teacher's own Drive and used it for attendance, random groups, a name picker and personalized emails to students and parents. I built it on my own between January and October 2026, with Claude Code writing most of the code under my direction. It went live in August, passed Google's OAuth verification in September, and I shut it down in October after testing it with colleagues at my school.
- Role
- Sole developer: research, design, development and operations
- Timeline
- January to October 2026
- Size of the build
- 287 commits, 277 co-authored with Claude Code, and 1,139 automated tests
- Outcome
- Shut down after user testing
Research
In January 2026 I surveyed teachers at my school in the Waterloo Region District School Board and got 39 responses from math, English, science, phys ed, guidance and special education. I then interviewed four of them for 15 to 20 minutes each, picking people who had given different kinds of answers.
Parent communication took the most time: about 74% of teachers spent more than five minutes a week finding past contact history and setting up emails before writing anything. Accommodations were the bigger risk: 70% said they had missed an accommodation they should have provided, and the board's system for looking them up averaged 2.4 out of 5. Most teachers were reasonably happy with how they made groups, usually with Flippity, and rated their current method 3.75 out of 5, so I treated grouping as a nice extra.
"I just need to know what the accommodations are. If I could just get a class list with the relevant accommodations, that would be great."Teacher interview, January 2026
Requirements
In February I wrote a product requirements document that set a baseline from the research and a target for each feature.
| Task | Baseline from research | Target |
|---|---|---|
| Send a personalized email to every parent in a class | 15 to 30+ minutes using an export and a mail merge | Under 5 minutes, 3 steps or fewer |
| Look up a student's accommodations | Several clicks across tabs in the board's system | Under 30 seconds |
| Teachers who report missing an accommodation | 70% | Under 20% after one semester |
| Make random groups with one exclusion | 8+ steps, re-entering the class list | 3 steps or fewer |
The document also listed open questions. The second one asked whether a school board would allow accommodation data in a tool it had not approved. I didn't answer it until August, and the answer ended up removing the accommodation feature.
Timeline
- Jan 2026Survey of 39 teachers and four interviews
- Feb 2026Product requirements document
- Apr 2026Development starts: React and TypeScript front end, Express server, Google Sheets for storage
- Jul 2026All five tools finished; work starts on accounts and a Postgres database
- Jul to Aug 2026Sessions, Stripe billing and two separate security reviews
- Aug 24, 2026Site goes live at teachneat.com
- Aug 31, 2026Accommodation tracking removed after a legal review
- Sep 24, 2026Google approves the app's OAuth verification
- Oct 2026Testing with colleagues and a feedback form
- Oct 18, 2026Decision to shut it down
- Oct 23, 2026Feedback form closes and shutdown begins
The product
Every tool works from the same class list. These screenshots are from a demo account with made-up students. Click any image to enlarge it.
Building it with Claude
I wrote very little of the code by hand. Claude Code, Anthropic's AI coding agent, wrote most of it over about 65 working sessions, and 277 of the 287 commits are co-authored with it. My role was closer to a product manager and tech lead: I decided what to build, wrote down how it should work, reviewed what came back and tested it.
On a project with accounts, billing, encryption and a Google security review, a few practices kept that manageable.
The planning documents were the spec
Six documents covered the implementation plan, the design system, the testing plan, the spreadsheet schema, the API contract and a list of approved dependencies. Every session started by reading them, and a hook made Claude ask me before editing any of them, so changes to the spec were always my decision.
Standing rules in a project instructions file
A CLAUDE.md file loaded into every session with the security, coding, writing and deployment rules. When something went wrong, the fix included a new rule there. For example, after a failed deploy went unnoticed, every session had to check the last CI run before saying anything was live.
Keeping the context small
The record of what to do next grew to 969 lines at one point, mostly repeated history, and every session had to read it. I moved completed work into a separate log and set a 250-line budget with a written procedure for updating the file, so each session started with only what it needed.
Parallel sessions that checked each other
I often ran more than one session at a time on separate parts of the app, and used a fresh session to review another one's work before it was committed. The two security reviews worked the same way, with one session hardening the app and a second one, asked to act as a security analyst and penetration tester, going over it again.
Testing and review before anything shipped
Every change had to pass the automated tests and the same checks CI ran, which a git hook enforced before any push. I tested features myself and reviewed every visual change before it went out, and the project rules required checking which version production was actually running after every deploy.
Key decisions
Student data stays in the teacher's Google Drive
The class list lives in a Google Sheet that the teacher owns. The server reads and writes it through Google's API but doesn't keep a copy in its database, logs or backups. I chose this because it's the first thing a school board's IT department asks about. It also meant the app only needed Google's lower-risk permission scopes, which avoided the yearly third-party security audit that broader access requires.
Pricing
I planned a free account with the everyday tools and a Premium plan at $6.99 a month or $69.90 a year (CAD) that added attendance statistics, more email and extra grouping options. The idea was that teachers would get used to the free tools first and then pay for the extras. Billing was built and tested with Stripe but never switched on.
Removing accommodation tracking
In August I looked into who is allowed to approve a third-party tool for special education records. In every jurisdiction I checked, that authority belongs to the school board, and a teacher agreeing to the terms of service doesn't change that. I removed the accommodation feature completely and limited the launch to Ontario, free for the first year. I still think that was the right decision, but it meant losing the feature tied to the strongest result in my research.
Measuring usage
For each account I tracked the first date it reached each milestone (adding a student, saving attendance, making groups, opening the name picker, sending an email) and a monthly count of how often each tool was used. I kept it to monthly counts so it would be easy to explain in a school board privacy review. That was still enough to see which tools people used and whether they came back.
User testing
Once the app was live, I shared it with colleagues at my school, explained what each tool did, and entered everyone who filled out the feedback form into a gift card draw. Before paying for insurance, a legal review and the other things a public launch needed, I wanted to know whether teachers would keep using it after trying it.
I looked at two sources: what the accounts actually did, from the app's usage tracking, and what testers said in a feedback form about how often they would use each tool and how likely they were to sign up for real.
What testers did (3 accounts)
- All three added students within minutes of signing up
- All three opened the Name Picker, 6 times in total
- None saved attendance, made groups or sent an email
- One came back once, a week later
What testers said (3 responses)
- Likelihood of signing up: 4, 4 and 2 out of 5
- Grouping had the highest expected use: 5, 3 and 5
- The Name Picker had the lowest: 1, 4 and 2
- One teacher said they wouldn't take attendance twice, once for the school and again for the app
"This looks useful and I like how later in the email you can send it to the group of students with high absences, but if I was being honest I probably wouldn't take attendance twice (once for the school and then once for me)."Feedback form, October 2026
What testers said and what they did didn't line up. The form answers were mostly positive about attendance and grouping, but none of the accounts saved attendance or made a group, and the one tool everyone opened was the one rated lowest. The comment above explains the attendance result. Teachers already take attendance in the school's system, and doing it again in Teachneat isn't worth the time. The attendance statistics, the high-absence email list and the idea of grouping only students who are present all depend on that attendance being entered, so this is a bigger problem than one unused tool.
Form responses aren't linked to accounts, so I can't match what each person said to what their account did, but they all came from the same small group of people. Three people is far too few to measure anything with confidence. I was looking for something simpler, which was whether people who knew me, understood the tool and had a reason to try it would start using it regularly. Over the test period, none of them did.
Why I shut it down
I wasn't convinced the product had a path to making money that was worth the cost and risk, for the four reasons below.
| What I found | What it meant |
|---|---|
| Accommodation tracking couldn't be offered legally | The tools that were left solve problems teachers told me were already handled reasonably well, often by free tools like Flippity |
| Testers didn't use the core tools | The free-to-paid plan depended on teachers using the free tools every day, and attendance would mean entering it twice |
| Nobody signed in with a school Google account | Reaching teachers on their school accounts needs each board's IT department to approve the app, which takes months per board |
| Costs start well before revenue | Hosting alone was about $31 USD a month, or roughly seven paying subscribers, before insurance, a legal review and tax registration |
I made the decision before committing to any of those costs. Insurance, the legal review, a business mailing address and tax registration were all planned but not started, so the total spent on the project was hosting, the domain and the business name registration.
What I would do differently
Answer the biggest risk first
Whether boards would allow accommodation data was an open question in my February requirements document. I didn't answer it until August, after the feature was built and live. A conversation with a board privacy officer in February would have changed the plan before I wrote any code.
Check where each feature's data comes from
Attendance looked like a strong feature on paper, but teachers already record it in the school's system. I should have asked, for each feature, whether teachers would have to enter the same information twice, and built around the answer.
Test whether people come back before building for launch
Accounts, billing, encryption key management and two security reviews were needed for a public launch, but not to find out whether teachers would use the tools. A simple prototype given to ten teachers for a month would have answered that much sooner and for much less. Having Claude write the code made building fast and cheap, and that made it easy to keep building past the point the evidence supported.
Work out how to reach teachers early
Most teachers work in school-managed Google accounts that the board's IT department controls. I planned board approval as a later phase. I should have tested it alongside the first prototype, because without it the app can only reach teachers' personal accounts.
Ideas for a future version
I kept a backlog of ideas with notes on how each would work. These are the ones I would start with if I came back to it.
| Idea | Why |
|---|---|
| Sync attendance and class lists with the school's student information system, such as PowerSchool | Removes the double entry testers objected to, but needs an agreement with each board |
| Import the class list from Google Classroom or a CSV file | Typing in a class list is the biggest setup job for a new teacher |
| Make groups from only the students present today | Suggested in the feedback form |
| Record each student's progress-report status for use in emails | Suggested in the feedback form |
| Drag a student to an empty spot to start a new group | Makes it quicker to adjust groups by hand |