How I work · Spyderboy Studio
From first call to shipped software
Every engagement starts in one of two places, a new idea or code you already have, and ends in the same autonomous loop that built every project on this site. Here’s what happens in between.
Download the one-page version (PDF) ↓
Where we start
A new product
What success looks like
We agree on the outcome first: who it’s for, what they need to get done, and how we’ll know it worked. No code yet.
The blueprint
We map every screen and what a person does on it, so the scope is exact before the build starts.
The tools
Picked for fast change and for running everywhere you need it, such as Flutter for one app on iPhone, Android and the web.
An existing codebase
Read the code
A close read of what you have: how it’s built, where the shortcuts are, and what’s risky to touch.
Check its health
What the tests cover today, what the code depends on, and how it behaves in use. Where coverage is thin, a test safety net pins down what it does now.
A plan before changes
A short list of what to fix and in what order, agreed before anything is touched.
Then the same engine
01
The plan
The goal becomes a roadmap with milestones.
02
Small tasks
Each milestone splits into tasks small enough to check on their own.
03
The queue
Xanadu builds them unattended, several at once when the job is big.
04
The watcher
A monitor keeps checking the run’s health and progress, and flags anything that stalls.
05
Fixes that stick
A mistake that repeats becomes a permanent rule, so later tasks don’t make it.
What it takes to run
3–10 min
per task
Most tasks go from start to tested and done in that window. The median is under five minutes.
Task times from Xanadu’s logs of 1,500+ completed tasks.
Jose Antonio Licon · dev@spyderboy.com · spyderboy.com/process