Work with us
There is no form, no discovery package and no sales call. You write, we read it properly, and we come back with what we actually think — including whether we are the right people for it.
Email us about your projectWhat happens next
This is the part before any building starts — the part nobody describes, and the part you are actually deciding on.
Whatever state the idea is in. A paragraph is enough, and a long document is fine too — we would rather read what you actually think than a version of it tidied up for us. If there is an existing product, a repo or a design file, send it.
Usually about the part you did not write down. Most briefs contain two products and a wish, and the useful conversation is about which one you actually want and what the hard part really is — often not the part that feels hardest.
Openly, and early. If it is something we want to build, we will say so plainly. If it is not, we will tell you that instead of quoting a number high enough to make it go away — and where we can, we will say what kind of team would suit it better.
What it does, what it deliberately does not, where the risk sits and what we would prove first. This is the step where we tell you what to cut, which is the least flattering part of working with us and the one that decides whether a first release is any good.
Definition, design, artwork, the app, the backend, the store listing and the releases after it. The whole arc, by the same people. The six steps below are what that actually looks like.
How a project runs
The sequence is the opinion. Anyone can list the same activities; the order is what stops a product being designed twice.
Most briefs contain two products and a wish. We take yours apart, argue about the scope, and come back with the version that can ship: what it does, what it deliberately does not, and where the hard part actually sits.
Not a clickable prototype. The actual difficult path, running on hardware, in the first fortnight. Camera to model to structured result. Scan to redirect chain to verdict. If that does not hold up, every screen drawn around it was decoration.
This is the step where we tell you what to cut, and it is the least flattering thing on this page. A first release that does a few things properly beats one that does everything approximately, and the difference is decided here rather than discovered in review.
Icons, a wordmark for each theme, the screens and the way they move, and the artwork that stops a product looking like five products. Drawn against real output and real strings, with the empty, offline, refused and failed states treated as part of the work.
Keys behind a server rather than in the client. Deny-by-default rules. A deadline on every call. Quota and entitlements enforced somewhere the user cannot reach. This is the half nobody demos and the half that decides whether the thing survives contact.
Listing, screenshots, the Data Safety answers, privacy and support pages at real URLs, staged rollout — then the crash reports, the drop-offs, and the release that responds to them. A launch is a hypothesis.
How we choose
For a long time the answer to any project was yes. It is a reasonable way to start and a bad way to continue: work you are indifferent to comes out indifferent, and everybody involved can feel it.
So now we pick. Not by budget or by industry, but by whether the problem is one we want to spend months inside — because that is the difference between a product someone built and a product someone cared about, and it shows in the parts nobody is paying attention to.
The useful part for you is that we say this at the start rather than after a contract. You will get a straight answer early, and if we take it on, you have someone who wanted the problem in the first place.
Work you are indifferent to comes out indifferent, and everybody can feel it.
Fit
Worth knowing before you spend time writing. Neither list is a judgement about the work — they are what one team doing the whole of something is structurally good and bad at.
Before you write
None of it is required — a couple of sentences is a perfectly good start, and we would rather hear the idea early than a polished version of it late. These just save a round trip.
The version you would say out loud to a friend, before it gets formalised. If you cannot get it into a sentence yet, say that — working out what it actually is happens to be the first thing we do anyway.
Whatever they currently use instead, even if the answer is a spreadsheet or nothing at all. What people already put up with tells you more about a product than a feature list does.
A running app, a half-finished build, designs, a repo, a research document. Nothing is too rough, and an honest description of what state it is really in is more useful than a tidied one.
A date that genuinely cannot move, a platform you are committed to, a regulation you are inside, a budget shape. Constraints make the answer more useful, not less — they are what a realistic first version gets designed around.
Start here
One email, read by the people who would build it. Tell us what you are trying to make and we will tell you what we honestly think.
support@snowylakes.comIf we are not the right studio for it, we will say so — and try to be useful about who might be.
