Good work can't be rushed
I can move quickly. Hattle went from a paper sketch to shipped in 8 hours. But fast because it was planned is very different from fast because corners got cut.
How I work
Questions first. Code second.
Freelancing taught me that the first thing someone asks for is rarely the whole story. So I ask a lot of questions, plan properly and build where you can see it. It's how I ship quickly without the quality dropping.
Q1What's the real problem?
Q2Who's it for?
Q3What does done look like?
then the code
go on, move them
The steps
From first message to handover.
Five steps. Flick through them like a notebook, or use your arrow keys.
01
Ask the questions that matter
What's the real problem? Who's it for? What does done look like? Working with clients taught me which questions uncover the real problem, and it's usually not the first one on the list.
What that covers
- The problem behind the feature request
- Who uses it and what they need
- What "finished" means to you
“He not only helped resolve my issues but he has a great way of thinking through the process.”
02
Plan it properly
The data, the access rules, the screens and the order to build them in. Knowing what you need to plan is how you ship fast without dropping quality. I learned that by getting it wrong a few times first.
What that covers
- Entities and who can see what
- The flows that matter most
- What ships first, and what can wait
getting it wrong on paper is free. getting it wrong in code is not.
03
Build in the open
You see progress as it happens, not one big reveal at the end. I explain what I've done in plain English, and I flag problems when I find them, not when they've grown.
What that covers
- Regular updates you can click through
- Problems flagged early
- No jargon unless you want it
“great to work with, really good communication!”
04
Check it, then ship it
Empty states, error messages, phones, keyboards, the security scan and what search engines see. The unglamorous checks are where apps usually break, so I do them before your users find them.
What that covers
- Real devices and awkward inputs
- Access rules and security scan
- Titles, previews and speed
“AJ is your guy if you care about attention to detail and quality…”
05
Hand it over
A walkthrough and notes, so you understand what you own and you're never stuck waiting on me. If you want me around afterwards, we agree what that looks like up front.
What that covers
- A walkthrough of how it fits together
- Notes you can come back to
- Support agreed up front, not guessed
you should never be stuck waiting on me.
swipe the page
Principles
Things I won't budge on.
Six rules I work by. A couple of them I learned by getting it wrong first.
Rule 01 Rule 02 Design for the people using it
Not for the screenshot. If something will confuse your users, I'll say so, even if it's in the brief.
“He doesn't put you in mind just as a client, he puts your users in mind…”
Megan Rule 03 Security from day one
Access rules go in when the data does, not in a panic the week before launch.
Rule 04 Fix the cause, not the symptom
A patch that hides the problem just means we'll meet again next month. I'd rather find out why.
Rule 05 Say it straight
If I'm not the right fit, I'll tell you. If it's a two-minute fix, I'll just tell you the fix.
“Doesn't look to sell me his services unless I need them and was ready to help for free because it was a 2 minute fix.”
holly.hates.mondays (Shadling) Rule 06 Learn in public
Most of what I know came from breaking things and asking questions in the Base44 Discord. I try to give that back with free guides and open-source skills.
Where it came from
What taught me to work this way.
that's me
Tooling
What I reach for on a project
The full list lives on my uses page. These are the ones that show up on almost every build.
Base44The platform: data, auth, backend functions, hosting.- Claude CodeAn AI coding agent in my terminal.
CodexOpenAI's coding agent. I pay for both, which tells you how that argument went.- GitHubVersion control, and two-way sync with Base44.
- StripePayments and subscriptions.
- ResendEmail that arrives.
- DenoThe runtime Base44 backend functions run on.
Fit
Who I work best with
People who know good work can't be rushed.
- You care about the detailsHow it feels to use matters to you as much as whether it technically works.
- You want the cause fixedYou'd rather sort out why something breaks than patch it every week.
- You think about your usersYou want the people using it looked after. The brief is only half of it.
- You'll tell me the messy bitsThe real constraints, the half-built parts, the thing you're worried about. It all helps.
Probably not a fit if...
No hard feelings. Better to say it now than halfway through.
- You need it live tomorrow and don't mind how it gets there.
- You want a quick patch over something that needs fixing properly.
- You want someone to agree with everything rather than ask questions.
- You mostly want the cheapest option going.
If that's you, that's completely fine. I'll point you somewhere better if I can.
FAQ
Process questions.
It depends on what you need, and I'd rather give you an honest estimate than a nice-sounding one. Once I understand the problem, I'll tell you roughly how long it'll take and what could make it longer.
Sound like how you want to work?
Tell me what you're building. I'll ask a few questions, then tell you honestly whether I'm the right fit.