How a studio engagement runs, from the first call to the handover

Most of what AppVerz does is the Mac apps. The rest of the year, the same people build products for other companies. Two of those are public and running: BestCard, a credit card finder for India with 531 hand-verified cards, and WealthTicker, a mutual fund screener that computes its own figures from public NAV history. People who find the studio page tend to ask the same question, which is what working with us is actually like. This is the answer, step by step.

Step one: a thirty-minute call

It starts with a call, and the call is about your problem, not our services. We ask what the problem costs you today, in money or hours or missed opportunities, and what "done" would look like if it went well. We do not bring a deck. By the end you should have a clearer brief than you arrived with, whether or not we end up working together, and we try to say honestly if the work is not something we should take on.

Most people who book the call have one of three situations. A product that should exist and does not yet. A platform or data pipeline that has to stay up and right every hour. Or a system the business already depends on that nobody dares touch. Those are the three kinds of work the studio does, and the call is partly to confirm you are in one of them.

Step two: a written scope within a week

After the call, you get a document. It says what gets built, what deliberately does not, what it costs and when it lands. The "deliberately does not" section is the one we spend the most time on, because scope that is left vague becomes the argument in month three.

The document is yours. You can take it to another studio, build it in-house or sit on it for a year. We would rather lose an engagement to a clear scope than win one on an unclear one.

Step three: working software every week

From the first week there is something you can click. Not a mock-up or a slide of what it will look like, but the real thing, running, with whatever part exists so far. The reason is simple: it is cheap to change direction in week one and expensive in week nine, and the only reliable way to find out a direction is wrong is to put the software in front of the person who has to live with it.

It is also the only honest way to scope. A feature that looked essential in the document often turns out to matter less once there is a working version to click, and one that nobody mentioned turns out to be the thing people reach for. Finding that out in week two is cheap. Finding it out at launch is not.

Step four: a handover that holds

An engagement ends with the client able to run the thing without us. That means documentation written for the next engineer rather than for us, a build anyone can reproduce from a clean machine, and a walkthrough for whoever is taking it over. The code is the client's outright; there is no licence back to the studio and no dependency on us staying involved.

We think about this from the first week, because a handover you only plan at the end is the kind that leaks. The habits that make the Mac apps work, native code, nothing hidden, honest about what the software does, are the same habits that make a system runnable by someone else afterwards.

What we bring from the apps

The studio and the apps are the same people, and that is deliberate. Everything we promise a client is already running in software we sell and support ourselves: a product designed and engineered by the same small team, support answered by the person who wrote the code, and a default of doing less rather than doing something you cannot take back. If you want to see how we think before you book a call, the apps are the portfolio. SweepyMac and FocusLens are each a few minutes to try.

Booking a call

The call is free and takes thirty minutes. Email the studio with a paragraph about the problem and we reply within two working days with times. The studio page has the details and the two case studies.