Web development, front to back.
Dmitrii has been writing software for six years, all of it on other people's teams until this one. The frontend, the database and the thing that sends the email are all the same person's problem, which is why they tend to agree with each other.
The whole thing, not a layer of it
Most studios stop at the browser and hand you a repository that needs a backend team to be useful. These three are one job here.
Frontend
A framework when the project needs one, plain HTML and CSS when it does not. This site is the second kind: three pages, no client-side JavaScript at all, because nothing on it needed any. The right answer is whichever one you can still change in a year.
- The right framework, or none
- Accessible from the first screen
- Fast on a mid-range phone
Backend
A schema designed before the first table is created, and an API that does not change shape every time a screen does. Accounts, permissions, payments and the third-party integrations that always take longer than anyone estimates.
- Data designed before it's built
- Logins, payments and integrations
- Background jobs and email
Running it
A deploy you can trigger yourself, backups that are tested rather than configured, and monitoring that tells someone when it breaks. Plus a handover document written for whoever comes after us, which may well not be us.
- Deploys and environments
- Backups and monitoring
- Written handover
You watch it get built, from week one
Work lands on a staging URL in two-week slices. It is a real URL on real infrastructure, not a screenshot in an email, and you can open it on a Tuesday afternoon and click through whatever exists so far. Nothing is saved up for a reveal.
That changes what feedback is for. Instead of approving a finished thing you cannot afford to change, you are looking at something half-built while changing it is still cheap. Most of the best decisions on a project get made this way, by someone noticing that a step feels wrong when they finally click it.
Start with the design side, or see the four phases in order.
Things people ask before starting
Can you build from someone else’s designs?
Yes. Send Figma files, a style guide or a half-finished site and we will build it. We will tell you where the design assumes something the data cannot do, because that conversation is cheaper now than later.
How do you choose the stack?
Per project, rather than selling everyone the same one. A marketing site and a product with accounts in it should not be built the same way, and the hosting follows from that too. Whatever we pick, you own it and the handover explains how to run it.
Do we own the code?
Yes, entirely. It lives in your repository under your account, and the handover document explains how to run it without us. We would rather you could leave than feel you could not.
What happens after launch?
We stay on for a stretch to fix what real traffic finds, because the first week is when you learn what you actually built. After that, some people keep us on a few days a month and some take it in-house. Both are fine.
How many projects do you take at once?
One, almost always. It is the whole reason the work gets the attention it does, and it is why we sometimes say no.
Have something worth building?
Tell us what you have in mind. A half-formed idea is plenty to start with. We take one project at a time, so the two of us read and answer every note ourselves.