Archon Soft is one person in Ankara who has spent about two years designing, building and shipping complete software products. Not a design studio that hands over screens, and not a dev shop that hands over a repository — the whole thing.
Being one person is the constraint and the argument. It is why scope has to be honest, and why nothing gets lost in a handover.
- Studio
- One person
- Based in
- Ankara, Turkey
- Working since
- About two years
- Live products
- Two
What that actually covers
Deciding what the product is. Drawing it. Building the client. Building the server. Modelling the data. Accounts and permissions. The admin the business will live in. Getting it live and keeping it there. Two products on this site went through every one of those steps with the same pair of hands.
- 01
Decide before you build
Most of the cost of software is set in the week before anyone opens an editor. That week gets spent properly, in the open, with the person who owns the outcome.
- 02
No handovers
Design and engineering are the same conversation held in two notations. One person carrying both means nothing gets lost between the file and the build.
- 03
Ship the smallest honest version
A narrow product that works beats a broad one that almost does. Scope is the first thing cut and the last thing padded.
- 04
Build the admin too
If the people running the business cannot change it themselves, the project never finished. The operations surface is part of the product, not an extra.
- 05
Write it down
Tokens, schemas, decisions and their reasons. A system nobody can read is a system only one person can maintain — and being that person is not a business model.
- 06
Hand it over properly
The work is finished when your team can run it without me. Documentation and handover are part of the build, not a line at the end of an invoice.
- 01
Frame
We agree on the actual problem, the constraints around it and what a good outcome looks like in plain language.
- 02
Shape
Structure, interface and architecture designed together until the product is specific enough to argue with.
- 03
Build
Short cycles against a working build. You see the real thing early and often, not a deck describing it.
- 04
Release
Launch, document, hand over. Then the part most people skip: the release after the release.
Tell me what you are trying to build and what is making it hard. If there is a fit I will say so quickly; if there is not, I will say that too.
- A reply
- Usually within two working days, from me.
- A conversation
- Scope, constraints, budget, timing. No pitch deck.
- A straight answer
- Including when I am the wrong person for it.