Would It Be Possible... Ideas That Lead To Apps
A friend called with a question that starts most good ideas: "Would it be possible to..."
She worked at a state university's adult-education program, the kind of role where you watch the same gap every semester. Adult-education instructors across the state, teaching GED prep, workplace literacy, basic reading and math to adults who'd missed it the first time around, wrote their own lesson plans. Nothing forced those plans to match the state's own academic standards. Nothing checked whether they did before an instructor walked into a classroom and taught from one.
What she wanted was an expert in the loop: a real education professional who could review a lesson plan and vouch for it before it went out to a classroom, or before another instructor found it and used it themselves. What she didn't have was a way to make that idea actually run at the scale a statewide program needed. Something instructors could use directly, without a curriculum office reading every submission by hand.
We built it — solo, from a friend's description of a problem she lived inside every day.
What got built
What it became, informally, was "the lesson bank": a web application that let instructors author lesson plans that conformed to the state's academic standards, structured so an expert educator could review and approve one before it ever reached another instructor's search results.
There were two subjects at launch, Reading/Language-Arts and Math, and each had its own shape. Building a lesson plan wasn't filling out one generic form. It walked an instructor through a 13-step authoring wizard, and depending on the subject and the grade band, the wizard asked for different things. Close to 70 separate fields across both subjects, each one there because a real state standard required it, not because a form template happened to include it.
The part that made that possible, the actual engineering underneath the wizard, was a form builder that stored its own logic as data instead of hard-coding it into the page. Which fields show up, which ones are required, which ones depend on an answer given three steps earlier: none of that lived in custom code written per form. It was a set of rules, defined once, and a single evaluator ran those same rules whether the check happened instantly as an instructor typed or again on the server when they hit submit. Add a new rule once, and it behaves identically in both places. That single detail is the difference between a form that quietly drifts out of sync with itself over time and one that doesn't.
Standards, vetting, and the paper trail
Every lesson plan mapped to the state's actual college-and-career-readiness standards, the full hierarchy, not a simplified summary of it. An instructor didn't just claim their lesson covered a standard; they picked the specific standard out of the state's own tree, and the system carried that mapping alongside the lesson itself, permanently.
Nothing published automatically. A lesson plan moved through a real lifecycle: drafted, submitted, reviewed by an expert educator, and only then published to the public bank other instructors could search and download. That review step was the entire point of the friend's original question: an actual person with education credentials looked at every lesson before it reached a classroom, not an algorithm and not an honor system.
Once a lesson cleared review, the system generated it automatically as a Word document, a PDF, and an HTML page, including math notation that rendered as actual math, not plain text standing in for exponents and fractions with carets and slashes. An instructor could pull a finished lesson plan straight off the bank and hand a legible, properly formatted document to a classroom the same day.
How it became a state program
The friend who made the original call didn't stay at the university. She moved on to work for the state's own adult-education agency. The lesson bank moved with the relationship, becoming a real cooperation between the university's adult-education academy and the state agency itself, running under a government domain the state owned, pointed at the server we ran and maintained. Not a pilot anyone was quietly hoping would end; a program the state ran.
We kept operating and maintaining the system for years after that first version shipped — the same application, the same statewide instructor base, growing alongside the program itself. A government domain draws near-constant probing on its own, and keeping that site hosted and secured was as much part of the job as building it in the first place. The friend, for her part, eventually passed the program on to others at the agency. The system outlasted the relationship that started it, which is usually a good sign for a piece of public software.
Who used it
Instructors across the state used the bank, and word travelled past the state's own borders: users in other states signed up on their own, with no formal partnership behind it. At its peak the bank had more than 2,000 user accounts and 309 published lesson plans that had cleared expert review: 160 in Reading/Language-Arts, 120 in Math.
Popular is the right word for it by user count, even though 309 approved lessons sounds modest next to that. The ratio says instructors came to search and use the bank far more often than they came to author and submit to it. That's exactly what you'd want from a public lesson bank, where most people are there to find something that already works, not to write something new. State staff presented the program at a national conference, and other states took notice. Nothing formal ever came of that interest, but the fact that it drew attention outside the state that built it says something about how unusual the underlying idea was.
The program ran for years before it eventually wound down, the way funding for public programs often does. That's not a knock on what it did while it ran — it did exactly the job it was built to do, for a public program that reached further, and lasted longer, than most software ever gets the chance to.
Building from an idea
We build software — sometimes that means rescuing a system that already exists, sometimes it means starting from nothing but an idea. This one started with nothing but a phone call and a person who knew a domain cold: what a state's academic standards actually required, what instructors actually needed, what "good enough" review actually looked like in adult education.
That's a different kind of proof than a migration number or a decade of uptime. It's proof that the distance between "would it be possible" and a real, adopted, statewide tool that thousands of people used for years is shorter than it looks — if the person asking the question knows their domain, and the person building it takes the idea seriously enough to make it real.
Stay updated on BitSalt’s work
Get notified when new tools launch and new posts go up. No drip sequence.