Harleypig

Working together

From "just do it" to "it's yours"

Every project is different, but the shape of working together stays steady and predictable. Here's the whole arc — from the first "here's what I want" to the day the finished thing is yours — so you know what to expect before you ever get in touch.

However you come in

People arrive at this from very different places. Here are three of the most common — see which one sounds the most like you.

"I want this. I have no idea how — just do it."

You bring the want, and nothing else — no picture of how it should work under the hood, and no need for one. That is a perfectly good place to start.

"I want this. I have some ideas."

You bring opinions — how it should look, what it should do, the parts you already care about. Good. We build from them rather than from scratch.

"I want this, and I've taken a run at it already."

You bring whatever you've already got: a sketch on a napkin, a pile of notes, a long back-and-forth with a chatbot, or code from someone you hired that didn't pan out. None of it is wasted — it all tells us something.

These are starting points, not boxes to tick. You don't have to decide which one you are — a short conversation places you. And here's the part that matters: the actual work behind the scenes — disciplined, tested, documented — is exactly the same no matter how you arrive. The only thing that changes is how much we check in with you and walk you through along the way.

One honest note: even a genuine "just do it" usually turns into wanting a few tweaks once you can actually see the result — especially the parts you look at and use. That's completely expected, and welcome.

Deciding what the first version is

Together we decide what that first version includes. It can be as bare or as complete as you like — shaped by how much you want in your hands up front, what you're able to spend, and how soon you need it. Two common shapes:

Built in stages

We agree on an order and build it a piece at a time — each piece finished and yours before the next one starts. A good fit when you'd rather spread it out, or watch it grow and adjust as it does.

A fixed budget

"Here's what I can spend." We agree together on what fits inside that, the team builds it, and you take it home. A good fit when the amount is the fixed point and the scope flexes to fit it.

The one thing we need from you: answers and decisions. Not technical ones — just you telling us what you want when a call is yours to make. Those go on a shared running list of questions you work through whenever it suits you: all at once at the start, in a burst near the end, or a few at a time as we go. Whatever rhythm fits your week, the team works around it.

That running list lives on a tool called GitHub — the same open place the work itself lives, so nothing about your project is tucked away somewhere you can't see it.

Before we build: a quote or a plan

Nobody should commit blind. There are two ways to find out what your idea takes before you say yes to building it.

A free consult, and a rough quote

A no-cost conversation where you tell us what you're after and we come back with the shape of it: the main features, a rough timeframe, and a ballpark of what it would cost. Enough to decide whether to go ahead.

A detailed proposal, for a fee

Want more certainty before committing? For a fee the team will do the deeper groundwork and hand you a full written plan, spelled out properly. If we go on to build together, you already have the map in hand.

What it costs to build tracks the size of the ask — a simple, single-purpose tool sits at one end; a large system with a lot of moving parts sits at the other. No surprise there, and no number here on the page: you'll always get the real figure in the consult or the proposal, never a guess pulled off a website.

What you walk away with

However you came in, you end up in the same place: a finished product that's fully tested and fully documented. Those tests and that documentation are yours whether or not you ever open them — most owners never need to, and that's fine. They're the safety net that lets the thing be changed later without quietly breaking, and the plain-language record that means you're never locked to us just to understand your own software.

There's more on exactly what that includes over on what you get.

Afterward: keep it, or we keep it

Everything up to this point is identical either way — the build is the build. The one choice left is what happens once it's done, and it's entirely yours to make.

Take it and go

We hand the finished product over and delete our own copy — we keep nothing. It's 100% yours: run it, change it, hand it to anyone you like. If you come back to us down the road, we treat it as a brand-new project and ask you where things stand now — not because we've forgotten, but because we genuinely kept nothing and won't assume it's gone untouched. Your software is yours, full stop; we don't hold a copy over you.

Leave it with us

The team keeps it and looks after it for a monthly fee. This comes in tiers that scale with how much there is to look after: a reply within a set response time (quicker on the higher tiers), bug fixes as things surface, keeping the underlying components up to date, ongoing security scanning for newly-discovered problems, and a set number of new features or changes each month. Which tier fits depends on the size of what you've got — we sort that out together.

Same build, your call on the ending. Handing it over and keeping nothing is the honest default — your software is genuinely yours. Leaving it with us is there for when you'd rather not think about the upkeep at all. Neither locks you in.

Have a project in mind?

Wherever you're starting from — a fully-formed plan or just a nagging "I wish this existed" — tell us about it, and we'll walk you through exactly how it would go.

Start a conversation