AutoTherm is a Windows desktop application for thermofluid engineering — heat transfer, fluid flow, the calculations a mechanical engineer or an engineering student does by hand, with a textbook open, and would rather not. It is built by ETR, LLC, a small firm led by Dr. Ben Zandi, an engineer with decades in the field. When we started working together in August the product was close to ready and not yet for sale. The job was everything around it: the website, the content library, the messaging, the signup funnel, the licensing and payment plumbing, so that when the software could be bought, launch would be a switch rather than a project.
Most of what we did would be familiar to anyone who has prepared a product launch. One part of it is the reason this piece exists, because it is a problem almost every founder-built website has and almost nobody budgets for.
The obvious plan
A company with a finished-looking website, a library of recorded walkthroughs, and a launch on the horizon is usually told to start driving traffic: ads, outreach to universities, SEO on the comparison pages, a LinkedIn push. The site is there, the videos are there, go get people to look at them.
That advice assumes the site is ready to be looked at by the people you want. For a technical product, that assumption needs checking before anything else, because the audience is engineers and faculty — people who read a feature table the way an auditor reads a ledger and who will hold a specific claim against the actual software. Sending that audience to a site before it can survive their reading is not marketing. It is spending money to lose credibility faster.
What we found when we read it the way an engineer would
The website had been written, reasonably, from the company's own strategy and messaging documents. Strategy documents describe where a product is going. Over a year of development, some of what they described had shipped, some had been renamed, and some was still on the roadmap — and the website hadn't been told the difference.
Working through it with the founder, we found roughly thirty-five places across the site where the copy described a capability the software didn't have in the form described. The biggest was a claim, repeated across five pages and in a comparison table, that the software displayed its own derivations step by step. It doesn't — it cites its sources, so a user can look up where a number came from. That is a perfectly good and honest thing to say. It just wasn't what the site said, and one of the named competitors in that comparison table genuinely does show its working, which meant the table was wrong in the most visible way possible.
The second pass turned to the competitor pages themselves. Facts about rival products had been written from memory and assumption rather than from the vendors' own sites. One claim about a competitor's business practice, complete with an imputed motive, was simply false. Two prices were overstated — one of them presented as a minimum when it was near the top of the published range. Every competitor fact in that section has now been checked against the vendor's own website, and the ones that held up — licensing terms, platform support, student pricing — stayed in, now sourced.
None of this was dishonesty. It was the ordinary drift between what a company plans and what it ships, landing on a public page nobody had re-read since the plan was written. Every founder-written site has some of it. The fix is a process, not a rewrite: anything said about a competitor is verified against that competitor's own site before publication, and anything lifted from a strategy or messaging document is checked against what actually ships. That rule is now part of how the site is maintained, and it is the most durable thing the engagement produced.
The rest of launch readiness
The video library. The founder had recorded a substantial set of worked-problem walkthroughs with no distribution, no metadata, and nowhere on the site to point people. We rebuilt the Resources page to hold them by discipline with deep-link anchors, wrote titles to length, descriptions front-loaded for search, and tags for every video, built thirty-two custom thumbnails to match the site's visual system, and documented an upload process in two passes — upload, then captions — after watching where the YouTube interface would have caused him to give up. The library is live in discipline playlists, fully captioned, and began picking up organic views without any promotion.
The videos looked grainy, and it wasn't the recording. Two causes, neither his. YouTube picks stream quality partly from the player's width on the page; below about 725 pixels it serves 360p no matter what was uploaded, and the site's inline players were around 520. Every video on the site had been served at 360p since launch. A lightbox that opens the video full-width fixed it — 720p on a laptop, 1080p on a large monitor, measured. The second cause is YouTube's two-pass encoding: uploads get a poor fast encode first and a better one only after enough views or if uploaded at 1440p or above, and a library of 1080p videos with low view counts sits on the poor encode indefinitely. That degrades exactly the small text and numbers in input boxes that are the content of a calculation walkthrough. The recommendation — export future videos at 1440p, even upscaled, since resolution is only the trigger — cost nothing. The recommendation against re-uploading the existing library mattered more: YouTube can't replace a file, so re-uploading would create new URLs and destroy the captions the founder had already done, and captioned material is often a prerequisite for university adoption.
A mobile menu that had never worked. The navigation drawer opened in the page's code and never painted, because a single CSS rule meant to stop horizontal scrolling had, per spec, turned the nav into a scroll container that clipped its own contents. Found and fixed in passing, along with a footer with no background, undefined style variables that made the card recommending AutoTherm look identical to the ones recommending competitors, broken breadcrumb links, and a handful of layout bugs on every comparison page.
A signup form whose email went to spam. The domain's authentication records — SPF, DKIM, DMARC — were all correct, which is where most people stop looking. The cause was that the mail plugin was authenticated as a different account than the one in the From line, so the domain's signing key was never applied and alignment failed on every send. Reconnected to the right mailbox, the form scores 10 out of 10 on deliverability testing, verified live.
Messaging that could survive the audience. The founder's own framing of the product's relationship to AI was sharper than the defensive version the site had: AutoTherm makes an engineer harder to replace rather than doing the thinking for them. That went on the home page. The tool count became "forty-plus tools, and growing" instead of a number that would go stale and invite counting. And the professor outreach email, originally written around the derivation capability that didn't exist, was rewritten around a hook that is both true and timely — faculty are worried students are outsourcing their reasoning to chatbots, and a deterministic, cited calculation tool is an honest answer to that.
Licensing and commerce, scoped so it wouldn't stall launch. We identified and evaluated a licensing vendor confirmed as a documented partner of the payment processor, costed hosted versus self-hosted and recommended hosted, which removed the longest-lead item from the plan, bounded the in-application integration to roughly twenty lines of code, and documented the merchant-of-record prerequisites that aren't obvious — including that the application triggers a compliance review of the live website and requires three legal pages to exist before approval. Two of our own early findings had to be corrected along the way when a vendor feature turned out to be withdrawn and a documentation page turned out to be stale, which is the same discipline turned inward.
What happened
By late September the website was accurate and tested end to end, the video library was public and gathering views, and the signup funnel delivered mail reliably. Nothing on the marketing side was blocking a launch. What remained was the founder's own work on the installer and documentation, and a licensing workstream he chose to defer — reasonable decisions for a one-person engineering team, and documented so the work can be resumed cold.
The thing we'd say to any technical founder about to launch: your website is the first spec sheet your buyers will audit. Make it say only what the product can prove, check every sentence about a competitor against their own site, and do that before you spend a dollar sending the right people to read it.