Build notes #1: what we got right and wrong in the first month
First in an irregular series of build notes. What we got right (brand-first, voice spec, the public roadmap as a planning artifact), what we got wrong (underestimating marketing scope, email infrastructure timing), and the open questions we're still working through.
Tree is a pre-launch product. We've been building for several weeks. The marketing site is live, the brand work is done, the roadmap is published, and the actual application is in early development. This is the first of what will become a series of build notes: honest reports about what we got right, what we got wrong, and what we're learning.
The series will be irregular. Build notes go out when there's something worth saying, not on a schedule. This first one covers the period from concept to first marketing site live.
What we got right
Building the brand before the product. Our instinct was to focus on the application and treat brand work as secondary. The roadmap, drawn as a tree, showed us that the brand prerequisites were upstream of almost everything else: marketing site, public roadmap, distribution, press. Without tone of voice, visual style, and identity, those downstream nodes were locked.
We did the brand work first. It paid off. The marketing site is on-voice, the roadmap is on-voice, the /vs pages and blog posts are on-voice, all because the voice spec existed before any of them were written. Teams who skip this step end up with inconsistent surfaces because they're inventing voice on the fly. We had a single source of truth, which made every subsequent piece faster to write.
Drawing the roadmap as a tree before drawing it any other way. This is the load-bearing decision of the early build. The tree structure surfaced dependencies the list format would have hidden. It made the brand-first decision obvious. It produced a roadmap that's actually useful as a planning artifact, not just as a marketing artifact.
The roadmap is also working as a dogfooding test. Every UI decision we make for the public roadmap is a UI decision the eventual product will face. We've already learned things about node states, edge rendering, and fog of war from the roadmap that will save us iteration time when the product ships.
Writing the voice spec early. The voice spec is a markdown file: principles, sentence-level patterns, banned words, anchor examples. We wrote it in week one. Every piece of copy on the site has been workshopped against it. The discipline of having a written voice doc is enormous. Decisions get made once, recorded, and applied consistently. New writers (including AI assistants) can be brought up to speed in fifteen minutes.
The cost of writing the spec was about three hours. The savings are uncountable.
Saying "no" to features publicly. The "Features we won't build" post forces us to commit to a shape. Once a refusal is published, walking it back has a public cost. This makes the constraints stickier than internal decisions would be. It also gives users a way to evaluate whether Tree is for them: if you want a workflow engine, this isn't the tool, and you can know that before signing up.
What we got wrong
Underestimating the marketing site. We thought the marketing site would take a week. It took longer, partly because the voice work was thorough and partly because the structure kept evolving. The /vs pages were a late addition. The /compare hub was a later addition. The blog was a later-still addition. Each one was the right call when we made it, but the total scope grew about 3x from the original plan.
The lesson isn't to plan more carefully. The lesson is that pre-launch marketing surface is hard to scope because you don't know what you need until you're trying to convince someone Tree is worth their attention. We should have budgeted more time from the start.
Treating the roadmap as a one-time artifact. We drew the roadmap, published it, and assumed it would be relatively stable. It hasn't been. Nodes have moved, branches have been added, prerequisites have been re-evaluated. The roadmap is more alive than we expected, which is fine, but we underestimated the maintenance overhead.
The fix is structural: the roadmap should be the same artifact the team uses internally for planning, not a separate marketing rendering. We're moving toward that. The dogfooding pressure is helping.
Not setting up the email infrastructure earlier. The waitlist signup integration with Kit took less time than the email infrastructure decisions that preceded it. Custom domain, sender authentication, deliverability, transactional vs marketing email distinctions. We did all of this last, when it should have been earlier. Several signups arrived before we had a welcome email ready, which is a small kind of failure but a real one.
The lesson: any user-facing surface that includes "we'll email you" is incomplete until the email is actually configured. We knew this in the abstract and still didn't sequence it correctly.
Underweighting the importance of writing. We knew copy would matter. We didn't realize how much. The brand voice work, the /vs pages, the blog posts, the FAQ, the in-app copy that's already being prototyped: all of it is writing, and writing well at this scale is genuinely hard. We've spent more total hours on words than on any other category of work.
This isn't a complaint. The investment is the right one. The miscalibration was thinking writing would be a smaller fraction of total effort than it's turning out to be. For an indie product without a huge ad budget, words are the primary distribution mechanism. We should have weighted them accordingly from the start.
What we're still figuring out
Three open questions we don't have answers to yet.
The line between authority content and SEO content. The blog posts so far have leaned authority: long, technical, opinionated, designed to be cited rather than to rank. This is the right strategy for our audience and stage. But the posts also rank for things, sometimes accidentally, and we haven't decided whether to optimize harder for that or to keep ignoring it. The current rule is "authority first, SEO second," which has been working, but it's a rule that was easy because we haven't faced a real tradeoff yet.
The line between transparency and oversharing. This post is at the edge of that line. Build notes are useful when they're honest and tedious when they're confessional. We're trying for the first. Whether we'll keep the discipline as the product matures is an open question.
The waitlist conversion rate to actual users. The waitlist is growing. We don't know yet what fraction will convert when the product ships. The number we expect (somewhere between 15% and 40%, depending on which startup advice you believe) covers a wide range. We'll know in a few months.
What's next
The next chunk of work is on the actual application. Marketing site is in good shape. Brand is in good shape. Distribution is working. The product itself is the gating constraint for everything downstream.
We'll write more build notes when there's more to say. If you want to follow along, the newsletter is the right channel. The waitlist gets product launch news; the newsletter gets these.
Join the waitlist if you want the launch. Subscribe to the newsletter if you want the build.