Tools
Rather than describe what Unit 3 produces, here is one you can use.
A single HTML file that turns messy notes into a checked schedule, a calendar file and a spreadsheet. Open it, paste something in, see whether it works. Then read how it was built.
- What it is
- One HTML file
- Size
- About 40 KB, 808 lines
- Dependencies
- None
- Server
- None — it runs in the browser
- Data sent anywhere
- None
- Build time
- One hour to specify, three to build
The problem
The gap is never the typing. It is that nobody wants to be the person who transcribed a date wrong.
Why this one.
Almost everyone who plans anything has the same twenty minutes of work: a set of dates and times exists in an email, a set of notes or the back of a programme, and it needs to become entries in a calendar. The information is all there. Moving it is dull, and it is exactly the sort of dull that produces a wrong date once a year.
It is also the kind of problem people do not commission software for. It is too small to pay a developer for and too fiddly to keep doing by hand. That gap is where Unit 3 lives: not building products, building the twenty-minute-a-week tools nobody else will ever build for you.
This one was built to be shown. It solves a problem that is general enough to be useful to a stranger, so you can judge the work without needing context about anyone's business.
On this page
The build
Four sessions, in the order the curriculum uses.
This is the Unit 3 sequence exactly as Sessions 14 to 17 set it out. The course has not been taught yet — January 2027 is the first cohort — so this build is not a participant's work and is not presented as one. It is mine: I built the tool against the unit's own sequence, an hour a week for four weeks, to find out whether the unit is teachable at the pace it claims before anybody pays to sit through it.
Specification
Before any code: what goes in, what comes out, what must never be guessed, and what this is not for. The intent file for this tool ran to roughly a page and took the full hour, most of it spent on the awkward cases rather than the obvious ones. That hour is why the build did not stall — and the file is still the thing that settles whether a change would be a fix or a mistake.
Produced: an intent file naming the input formats to accept, three output formats, the cases that must never be guessed, and what the tool was never meant to do.
First working version
Dates and times in the common shapes, a table of results on screen. Nothing handled gracefully, nothing styled, no downloads. It ran.
Produced: something that worked on clean input and broke on everything else.
Edge cases and validation
The long hour. 03/04/2027 is genuinely ambiguous and there is no correct guess. A year is often missing. An end time can be before a start time. 30 February exists in notes and not in reality. Each one got a decision, and the decisions are visible in the output rather than buried.
Produced: the three-state result — converted, converted with a stated assumption, set aside.
Interface, hosting and handover
Making it usable by someone who did not write it: the example button, the plain-language flags, the counts at the top, the syntax note that opens only if you want it. Then the calendar and spreadsheet exports, both to a real standard rather than something that merely opens on one machine — and then one file, uploaded, live at a URL, linked from here. No account, no build step, nothing to renew.
Produced: a finished tool, a calendar file that validates against the iCalendar specification, and the page you can open right now.
None of those hours involved writing code from a blank page. They involved deciding precisely what the thing should do, describing it well enough to be built, and then testing it hard enough to find where it was wrong. That is the skill the unit teaches, and it is the one that transfers.
It is also the method behind the rest of what I have built with these tools — the trip sites, the document generators, the records pipeline — which is set out with the counts on the instructor page.
The design decision that matters
What it refuses to do.
Session 16's line is that a tool which guesses quietly is worse than one that refuses loudly. This is that principle, built.
It will not resolve an ambiguous date
03/04/2027 is 3 April to most of the world and 4 March to the United States. The tool sets the line aside and says why, until you tell it which convention to read. It never picks one and hopes.
It will not date a relative reference
“Next Tuesday” means something different depending on the day the file is opened. Rather than silently anchor it to today, the line is set aside for a human to resolve.
It states every assumption it does make
A missing year, a missing end time, a line with no time at all: these get a stated default and a flag on the row, and the flag travels into the calendar entry's description. You can always see what was inferred.
Anything set aside is excluded from the calendar file entirely. The counts at the top of the results say how many, so a line cannot go missing without being noticed.
Scope
What this is not.
- Not a product. No account, no sync, no recurring events, no time zones, no invitations. It does one job for one person.
- Not client work. It was written for this page. The tools built during the course belong to the participant and are never shown here, under any circumstances — see the confidentiality commitments.
- Not a claim about your tool. Yours will be whatever you actually need. Unit 3's example build is a converter because that problem is common; if your twenty minutes a week goes somewhere else, the unit goes there instead.
- Not finished, in the sense that software is never finished. It handles the cases in the specification. It will meet an input it does not understand, and when it does it will say so rather than invent something.
Schedule Builder
Free, no account, nothing uploaded
The whole tool is one file you can save and keep.
- Input
- Plain text
- Outputs
- .ics and .csv
- Network calls
- None
- Cost
- None
This is one of two you would build.
Unit 3 builds a tool you need over four sessions, then a second one inside a single session, to establish that the method works without me sitting there.