·3 min read

The weekend plugin: how we ship in 48 hours without skipping QA

Scene Compass went from empty folder to Asset Store submission over one Saturday and Sunday. Here is the process we follow so "shipped fast" does not mean "shipped broken".

Ahmed Qaddoura
Ahmed QaddouraCo-Founder & Lead Engineer
ProcessUnityQAAsset StoreScene Compass

Scene Compass, weekend one

Scene Compass shipped to the Asset Store ten days after we first typed the words "tiny editor tool for measuring things." Seven of those days were the Unity review queue. The actual build was one Saturday-plus-Sunday, eight hours of focused work each day.

People ask how. They usually expect some trick — a template, a starter kit, a secret time-shortcut. There isn't one. There's just a process we follow every time.

Saturday morning: the cut list, not the todo list

The first ninety minutes is always a cut list, never a todo list. We write down everything the plugin could do, then we strike through ninety percent of it. The surviving ten percent is the MVP.

For Scene Compass the full brainstorm had 31 features: volumetric measure, screenshots with annotations, CSV export of measurements, "favorite" gizmo colors, team sync via Git, etc. The version that shipped had two: measure and bookmark.

This is the most important discipline we've internalized. The temptation to add one more feature is strongest before the first line of code, because everything still feels cheap and imaginary. After Saturday morning, new features are expensive.

Saturday afternoon: architecture, then core loop

We don't start with the UI. We start with the data model — what's the smallest struct that describes a measurement, a bookmark, a group? Then we write the code that persists them. Only then do we touch Scene view callbacks or ShortcutManager hooks.

By Saturday evening, Scene Compass could create, persist, and render a measurement. No UI polish. No keyboard shortcuts. No settings. Just: does the core verb work?

The rule: at the end of day one, you should be able to walk away and have shipped something. It doesn't need to be pretty. It needs to work end to end.

Sunday morning: polish and the unhappy paths

This is where most weekend projects go to die — the author loses momentum because the "fun" part is over. We have a checklist for this exact situation.

The Sunday morning checklist:

  1. What happens if the user presses the shortcut twice?
  2. What happens if there's no scene open?
  3. What happens on a fresh project with no bookmarks file?
  4. What happens if the bookmarks file is malformed JSON?
  5. Does it work on Unity 2020 LTS, 2022 LTS, and 6000?

Each item becomes a bug report or it doesn't. If it does, we fix it. If it doesn't, we write a note in the README so we remember we checked.

Sunday afternoon: documentation and the submission package

The README is a product — maybe the most important one. Our Sunday afternoon is spent writing the README, capturing clean screenshots, and filling out the Asset Store publisher form.

The rule for the README: a Unity developer should be able to read it in 90 seconds and know (a) what the plugin does, (b) how to install it, (c) what hotkey to press first. If it takes longer, we're hiding the lede.

The trick is not the speed

"We shipped in 48 hours" is a bad framing. The real claim is: we shipped a finished thing in 48 hours, because we defined finished in the first 90 minutes.

Most weekend projects fail by scope, not by hours. Ours don't fail because we decide what we're not building before we build anything.

Ahmed Qaddoura

About the author

Ahmed Qaddoura

Co-Founder & Lead Engineer

Unity and full-stack engineer with 10+ years shipping games, apps, and tooling. Co-founder of Simple Yet Efficient. Building the plugins you didn't know you needed until you did.

Keep reading