ServicesTaking over software

We’ll take over the software you already have.

A website, web app, or iPhone app someone else built. Maybe the developer moved on, progress stalled, or nobody’s quite sure how it all works anymore. We learn it, keep what’s working, and take responsibility for moving it forward, so you don’t have to become its project manager.

Tell us what you haveHow we start

What we found

Where everything lives

  • Code, hosting, domains, and DNS
  • Every service it depends on, and who pays for it

How to run it

  • Local setup, tested from scratch
  • How a change gets to production

Handle with care

  • The integration nobody’s touched in years
  • The deploy step someone does by hand

Leave alone

  • The parts that already work
The kind of notes we write first, and leave behind.

When to call

Sound familiar?

  • Your developer is moving on.

    Or already has. The software still needs someone who knows how it works, and you’d like that settled before something breaks.

  • Progress has stalled.

    Small changes take weeks, every fix seems to cause another problem, and nobody can say exactly why.

  • Nobody wrote anything down.

    It works, but how it works, where it’s hosted, and which accounts it depends on live in one person’s head.

  • You’re wondering about a rewrite.

    Before you spend that budget, get an informed opinion on what actually needs to change. Sometimes it’s a rewrite. Often it isn’t.

  • There’s a feature you need, and you’re nervous.

    It has to go in without breaking the parts your customers rely on every day.

  • It needs a redesign, not a demolition.

    A better design and a better experience, on top of a product that already works underneath.

  • You inherited it.

    A new role, a merger, or a vendor that moved on left you holding software you didn’t choose. It’s unfamiliar, and it’s still valuable.

Websites, web apps, and iPhone and Mac apps. Whatever it is, the first step is the same.

What taking over means

One team that owns it, and tells you what’s going on.

Taking over means taking responsibility: for the code, the hosting, the accounts, the deploys, and for telling you where things stand in plain English. You get one point of contact who knows how your software works.

If a request is bigger than it looks, we’ll say so before it turns into a surprise. If we think an idea will cause trouble, we’ll say that too.

“You should not need to become a web developer just to make sure the web developer is doing the job.”

From What “Quiet Mind” Means to Us

How we start

First, we read it.

Unfamiliar code isn’t bad code. Before we recommend anything big, we find out what the software does, why it does it that way, and what it would really cost to change.

  1. Find everything

    Code, hosting, domains, DNS, third-party services, and the accounts that pay for them. We find out where it all lives and who has access to what.

  2. Get it running

    A working local copy and a deploy we’ve done ourselves, so the first real change isn’t also the first experiment.

  3. Read it

    How it’s put together, which parts are solid, which are fragile, and which strange-looking decisions are quietly protecting you from an old problem.

  4. Fix what’s urgent

    Security issues, broken forms, failing builds. Small, careful changes first, each one tested and easy to undo.

  5. Tell you what we found

    In plain English: what’s working, what isn’t, what we’d keep, what we’d change, and what each option costs in time and risk.

  6. Move it forward

    Features, fixes, redesigns, and upgrades, made in the existing system wherever that’s the better call, and written down as we go.

Starting over?

Rewrites have to earn it.

Sometimes the foundation really is the problem: the platform is obsolete, critical dependencies are abandoned, or every ordinary change costs far more than it should. When that’s true, we’ll show you why, and plan a migration that keeps the old system doing its job until the new one is ready to take over.

More often, the better move is a handful of smaller fixes that remove most of the pain and keep everything that already works.

“The size of the solution should be proportional to the size of the problem.”

From The Case Against Starting Over

Proof

Picking up where someone else left off.

The clearest examples are our own: an open-source project we didn’t start, a live product we changed at its core, and the habit of writing things down.

Open-source Firefox extension

Easy Screenshot Plus

We started out as users of Easy Screenshot, an open-source Firefox extension. Fixing one small annoyance (it never saved where we wanted) meant learning someone else’s codebase, and we kept going.

Editable annotations meant revisiting an early decision. The original drew shapes straight into the image, so once something was drawn, it was just pixels. We moved annotations onto a layer of their own, which made selecting, moving, and undoing them possible, without giving up the fast, in-browser workflow that made the extension worth using.

Read the case studyeasyscreenshotplus.com

Burn After encrypting a file in the browser before it’s uploaded.

Our product

Burn After

Changing the core of something people already use.

After launch, the feedback was about trust, so we moved Burn After’s encryption into the browser. Most work on existing software looks like that: an important, structural change to something people already depend on.

Read the case study

The Quiet Mind Wiki’s macOS Bootstrap guide: prerequisites, then the commands to run.

Documentation

The Quiet Mind Wiki

Writing it down, so nobody has to guess.

Our wiki keeps knowledge out of source code and out of anyone’s head: setup guides, architecture decisions, and the script that sets up a new Mac from scratch. When we take over your software, what we learn gets written down too, so whoever comes next starts from notes instead of guesswork.

Read the case studyquietmind.dev

From the blog

Worth reading first

  • · 6 min read

    The Case Against Starting Over

    A rebuild can feel like the cleanest solution to a messy website. Often, the better decision is to keep what works and fix what does not.

  • · 4 min read

    What "Quiet Mind" Means to Us

    Quiet Mind is not about minimalism or a particular design style. It is about the confidence that comes from knowing the work is handled.

Before you ask

Questions

Our code is a mess. Is that a problem?

Probably less of one than you think. Code that looks messy often holds years of real decisions, and code that looks tidy can still be wrong. We’ll tell you what we find, without the drama.

Are you going to tell us to rewrite it?

Not by default. A rewrite is one option among several, and usually the most expensive one. If we recommend it, we’ll explain what it buys you that fixing the current system can’t. More in The Case Against Starting Over.

What do you need from us to get started?

Access: the code, the hosting, the domains, and the accounts behind any services it uses. Whatever documentation exists, even if it’s out of date. And someone who remembers why things are the way they are, if that person is still around.

What if it’s built with something unusual?

Tell us what it’s built with and we’ll be straight with you. We work across the web and Apple’s platforms, and an unfamiliar framework is no reason to start over. If it’s outside what we can own well, we’ll say so before you’ve spent anything.

Will you keep working on it after the first fixes?

If you’d like us to, yes. Or we’ll get it stable, documented, and ready for whoever comes next, whether that’s your own team or someone else.

Contact

Tell us what you’ve inherited.

What it is, what it’s built with if you know, and what needs to happen next. We’ll start by reading it.

Book a consultationStart a project