Constraints
CoStudy started at a design hackathon at Boston University. Brock and I were undergrads. The first idea was an app to help students find study partners. We pivoted to a scheduling tool for students with hectic and atypical hours. Then we pivoted again to what it is now: a peer-evaluation and reflection platform for higher education.
Brock isn't technical. I've been the only person on the design, engineering, infrastructure, and deployment side for seven years — Figma to TypeScript, schema design to production debugging at 11pm on a Sunday during midterms. Brock runs sales, customer relationships, and strategy. Support we split — operational tickets go to Brock, anything that needs the code to be opened comes to me.
What stuck: peer evaluation as the wedge
We did the first pivot on instinct. The second one we earned.
Summer 2020, Brock and I joined an accelerator at NYU and ran around fifty customer interviews in two weeks. The pain that came back repeatedly was evaluating peer performance in group work — and the timing was loaded. COVID had moved every class online; every professor we talked to was trying to integrate group projects into a remote semester and didn't have a clean way to measure who actually contributed.
That's when peer evaluation stopped being one of several candidate problems and started being the problem. Study groups had no buyer. Student scheduling was too generic, competing against Google Calendar. Peer evaluation had a buyer (the professor), a recurring event (every assignment), and a real workflow gap. We shipped the first version that fall.
One person across the whole stack
For seven years, every line of CoStudy's code has been mine. Every Figma frame, every schema change, every support ticket I have to debug, every deploy. Brock runs everything else.
I can ship in a day what a team would spend two weeks aligning on. Fewer meetings, no context-switching tax, the design and the code converge because the same person is doing both.
AI moved the math in the last two years. A week's worth of work fits into a day or two now. The product hasn't expanded its ambition — the throughput has.
What I think about more is the constraint. Every choice has to be one I can still maintain alone in five years. That rules out exotic infrastructure, abstract frameworks, and schemas no one else would want to inherit. Components live in my head, not in a library of 200 variants. Bugs get fixed fast because the person who shipped them is also the person who triages them — but the bus factor is one.
It's the part I can't engineer my way out of.
Per-student, per-semester
Pricing is per-student, per-semester. Cheap enough per seat that a professor can champion it inside the department without dragging it through full procurement, predictable enough at the term boundary that the department can budget against it.
What I cut
LTI — the standard that lets an ed-tech product live inside Canvas, Blackboard, or Moodle as a single-sign-on integration. Students don't have to manage a separate login; the product opens inside the LMS they're already in.
I cut it to ship the first version. Building LTI properly is a multi-week project on a standard with real edge cases, and we were trying to find product–market fit, not satisfy a procurement committee. We shipped without it, found PMF, and rode that for years.
It's been the right call until recently. Some schools now won't onboard without LTI — their professors love the product but can't get past their tech committee. It's the next thing in the queue.
Seven years in
A few thousand students per semester across a dozen universities. Department-level licensing. It's the one product in my portfolio still shipping seven years in. I'm still the only person writing the code. Visit CoStudy ↗
What I'd do differently
The hardest thing about ed-tech isn't the product, it's the purchase. Departments decide. Professors choose what to assign. Students actually take the evaluations. The student — whose attention determines whether the product is good — has no say in whether it gets bought, and the buyer often never opens it. For years I navigated this by tackling each conversation as it surfaced: professor UX first, department procurement when sales pushed back, student experience when I had time. The lesson is structural. Department procurement isn't downstream of the product; it's part of the product. If I were starting again, I'd treat all three audiences as three design problems from day one.