Phasewell is a made-up company, yet anyone who has hung around quantum computing startups will recognise its team instantly. Five people, two of them with physics PhDs, building a simulator that lets developers prototype quantum circuits in the browser. Brilliant engineering, tiny budget, and a public website that was supposed to attract early users. This is the story of how Phasewell’s scattered marketing setup nearly sank its launch, and how pulling everything into one shared workflow turned things around. Grab a coffee; it is a story about superposition of a different kind, where every task seemed to be in several places at once and none of them collapsed into “done”.

Meet the team and its scattered setup

Priya, the CEO, handled fundraising and most of the writing. Tomás built the simulator’s core. Mei ran the front end and, by default, the website. Ola managed community channels and partnerships. Dev, the newest hire, split his time between documentation and whatever else needed doing.

Nobody had “marketing” in their title, so marketing happened in the margins. Priya kept a list of blog topics in a notes app. Mei had run a website scan before launch and saved the report somewhere in her downloads. Ola tracked a handful of creators, physics explainers on video platforms and newsletter writers, in a spreadsheet with columns like “replied?” and “maybe?”. Dev checked whether the docs appeared in search results by googling them every Friday, when he remembered. Images and diagrams lived in four different cloud folders.

It worked, more or less, until launch month.

The launch that wobbled

Phasewell published a much-anticipated tutorial explaining how its simulator could visualise optimisation problems, the kind of thing we covered in our explainer on how quantum algorithms tackle stubborn optimisation tasks. Ola had lined up two creators to share it. Priya posted it on social media. Traffic arrived.

And then it bounced. The tutorial’s interactive circuit embed failed on mobile. The signup button on the landing page pointed to an old staging URL. The site’s SSL certificate was eleven days from expiry, and a browser warning was not far off.

Here is the painful bit. Mei’s scan from weeks earlier had flagged the signup button. Dev had noticed the mobile embed issue and mentioned it in chat, where it scrolled away under a debate about qubit noise models. Nobody had looked at the certificate since setup. Every problem was known to someone. None of them belonged to anyone.

The retro: “we have a workflow problem, not a tools problem”

The team held a blunt retrospective the following Monday. Tomás, who had spent years in research labs, put it nicely: “In the lab we would never run an experiment with the protocol split across five notebooks. Why are we running our website that way?”

They drew their process on a whiteboard. Problems were found in one place, discussed in another, fixed whenever someone had a spare hour, and never rechecked. Creator outreach lived in a separate universe from the content it was supposed to promote. The team agreed on three goals:

1. Every problem found on the site becomes a task with a named owner.
2. Routine checks, including site health, rankings and certificates, run automatically.
3. Content, creators and fixes live in one shared workspace the whole team can see.

Trying a consolidated workspace

Ola suggested they try WizBrand, a platform for running SEO work and booking creators side by side, mostly because it covered both her outreach and Mei’s site fixes. Here is what they actually used:

• Site audit: the first scan surfaced the staging-URL button, oversized images and several pages missing descriptions. Mei turned each one into a task and assigned it, some to herself and some to Dev.
• Creator marketplace: Ola used it to look up creators by platform and location and book them, instead of juggling DMs and a spreadsheet.
• Team features: everyone got an invite with sensible permissions, so Dev could close his tasks without being able to change billing or account settings.
• Nightly rechecks: audits, keyword positions and the SSL certificate were re-examined each night, so the certificate problem could not sneak up again.

It was free while in beta and did not need a credit card, which, for a five-person startup counting every euro, made the decision easy.

Week one: the uncomfortable list

The first week felt worse before it felt better. Turning every finding into a task produced a list of twenty-three items. Dev groaned. Priya pointed out that the list had always existed; it had just been invisible. Now, at least, it had owners and dates.

They triaged together in fifteen minutes. Anything blocking signups went first. Anything affecting mobile went second. Cosmetic warnings went to the bottom or got dismissed.

Weeks two to four: the routine settles

By the second week, a rhythm had emerged. Every Monday, Mei reviewed anything new the overnight checks had found and assigned it. Mid-week, people closed tasks in the same place they received them, so nobody had to ask “is that done?” in chat. On Fridays, Dev looked at how the docs pages had moved since the previous check and suggested one topic for the following week.

Ola’s outreach changed too. Because creator bookings sat alongside content tasks, she could time a creator’s video to land after the related tutorial was fixed and live, rather than before. That sounds minor. It was the difference between sending new visitors to a broken page and sending them to a working one.

What changed, honestly

Phasewell did not become famous overnight. What did happen was quieter and arguably more valuable:

• The signup bug, mobile embed and certificate were all fixed within a week of the retro.
• Two regressions after later deploys were caught by the nightly checks before users reported them.
• Dev stopped googling the docs every Friday; the history was already recorded.
• The team’s chat got calmer, because status questions largely disappeared.
• Ola’s second round of creator partnerships pointed at pages that actually worked.

Tomás summed it up at the next retro: “We fixed our website the same way we fix our circuits. Fewer moving parts, clear measurements, repeat until stable.” Our own guide to designing tidy quantum circuits would approve.

Priya also noticed something she had not expected: investors asked fewer anxious questions. When a potential backer visited the site during due diligence, it simply worked. She could not put a number on that, but she was certain it mattered.

Lessons for emerging-tech teams

If you are building in quantum, or any deep-tech field where the core product eats all your attention, Phasewell’s story has a few friendly takeaways:

1. Assume marketing work is happening in the margins. Find out where, and count the places.
2. Treat a known problem without an owner as unfixed. Because it is.
3. Automate the boring checks. Certificates and broken links should never depend on memory.
4. Keep creators close to content. Outreach works best when it is coordinated with what is actually live.
5. Expect an ugly first list. It is not new mess; it is old mess, finally visible.

Deep-tech teams pride themselves on rigorous process in the lab. The friendly nudge from Phasewell’s story is to bring a little of that rigour to the workflow that introduces your work to the world. One shared place, clear owners and checks that run themselves: not quantum physics, but surprisingly powerful.