Before You Build
Web AppShut Down

College Conductor

College Conductor targeted a narrow education workflow with an apparent close-at-hand first user. The founder later said he lost that user before delivering enough value, while stack complexity and package maintenance displaced customer development.

View original story

Product snapshot

What it was

College Conductor was a side-project SaaS for independent education consultants and college counselors to track students, schools, applications, and deadlines.

Who it was for

independent education consultantscollege counselors

Problem / value

Centralize student and school-application tracking so counseling workflow management felt less clunky.

Core workflow

Counselors tracked students, colleges, application deadlines, and admissions details from one workflow.

Product form

web appopen source repository

Pricing model

No public pricing data found in the sources used.

Competitors or alternatives

existing online tools for independent education consultantsspreadsheets and manual counselor workflowsvertical CRM/workflow tools for education consultants

What happened

Summary

The founder says College Conductor was shut down after three years of running the SaaS.

Core risk

Overbuilt Stack And Slow Customer Validation

Timeline

  • The founder ran the SaaS effort for three years before shutting it down.
  • The founder later used the project as teaching material for Django SaaS development streams.
  • The public GitHub repository shows College Conductor as a side project / experiment.

Before you build

Why it matters

This is a direct solo-founder SaaS postmortem with concrete lessons about choosing familiar tools, shipping a useful MVP quickly, and maintaining active customer-development pressure.

Primary check

Deliver a narrow counselor workflow to one committed user before investing in stack complexity or broad product scope.

Checklist

  • Can you name the first buyer segment and the repeated job they need solved?
  • Can you reach that segment without relying on one fragile channel?
  • What evidence would disprove the overbuilt stack and slow customer validation risk?
  • A narrow vertical does not remove the need for repeated customer development.
  • Unfamiliar frontend and deployment choices can consume the limited energy a solo founder needs for customer learning.
  • For a first SaaS, the fastest path to a useful customer workflow is usually more valuable than a technically ambitious stack.

Relevant if

  • You are building a similar web app with public-source distribution risk.
  • You need to validate who will repeatedly pay before investing in product polish.

Less relevant if

  • You already control a reliable acquisition channel for the exact buyer segment.
  • The product is an internal tool with no need for public distribution.

Pre-build tests

  • Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
  • Ask users to commit to a paid pilot, not only to join a free waitlist.

Transferable lessons

  • A narrow vertical does not remove the need for repeated customer development.
  • Unfamiliar frontend and deployment choices can consume the limited energy a solo founder needs for customer learning.
  • For a first SaaS, the fastest path to a useful customer workflow is usually more valuable than a technically ambitious stack.