9 resources from Joel on Software we point founders to, and the questions each answers.
✍️ Essay
✓ Link checkedFreeIntermediate
Why we picked it
This is the canonical warning against throwing away working code and rebuilding from scratch, told through Netscape's rewrite that handed years to competitors. Read it before you convince yourself the messy MVP needs a clean-slate v2: it names the exact trap you are about to walk into. Treat it as a starting point, not gospel, since sometimes a rewrite really is right, but the burden of proof is on you.
Old code that looks ugly is usually carrying years of hard-won bug fixes and edge-case knowledge you cannot see, and a rewrite silently throws all of it away.
It is harder to read code than to write it, which is why the instinct to rebuild almost always feels stronger than it should.
Most of what tempts you toward a rewrite (architecture, slow spots, cosmetic mess) can be fixed incrementally through refactoring instead.
Why we picked it
This gives you the sharpest rule for the build versus buy call: if it is a core business function, build it yourself, and if it is not, buy it. Spolsky's line maps almost exactly onto the question you are asking, because auth, payments, and email are rarely the thing customers pay you for. Use it as a one sentence test you can apply to every piece of your MVP.
Why we picked it
This is the founding text on interviewing programmers, written by someone who actually ran a software company. It argues you are hiring for people who are smart and get things done, not for trivia or a specific tech stack, and it shows how to read a candidate's reasoning as they work a problem out loud. Even if you cannot code, the idea of watching how someone thinks through a question (not whether they land the perfect answer) is exactly the muscle this whole question is about.
Why we picked it
This is the clearest statement of the exact idea in our answer: a spec describes how the product works entirely from the user's point of view, and says nothing about how it is built. Spolsky, who shipped Excel and later founded Trello and Stack Overflow, spells out that your job is screens, flows, and what happens when the user clicks, not databases or architecture. Read it and you will stop apologizing for not knowing the stack.
Why we picked it
Part 2 tells you what a spec is, this one covers who writes it and how they build agreement without authority, walking through Spolsky's own experience owning the spec for a real feature. It shows that a good spec is a tool for consensus, not a command, which is exactly the register a non technical founder can write in. You will see the spec as a conversation you lead, not a document you dictate.
Why we picked it
Spolsky shows why big vague tasks hide the truth and why breaking work into small pieces surfaces real progress. That is the same logic behind demanding demonstrable milestones from an agency: small units you can actually check. It also explains why 'we are 80 percent done' means almost nothing.
Why we picked it
This makes the case that working software should be produced and integrated constantly, so a broken or stalled build is caught in a day rather than a week. For an offshore team, an automated daily build is accountability that runs while you sleep: either the code compiles and works, or it does not. It is a short, practical read on making progress visible in the artifact itself instead of in a status report.
Why we picked it
This is a three-minute list of yes/no questions you can literally walk through with the developer you hire, or use to size up the agency's habits. Questions like 'do you have testing?' and 'can you make a build in one step?' turn a vague worry into a score anyone can read. It is the fastest way to convert 'is this code any good?' into concrete things to ask about.
Why we picked it
Spolsky's classic essay explains why willingness to pay for the identical product varies wildly by customer, using the image of a camel trader who will pay far more for the same rope than someone buying a rubber duck. It is the clearest argument you will find for why a single list price is the wrong question to start with when you have no comparable to copy. Read it before your first pricing conversation, not after.
