W·01
Internal tools
That one spreadsheet nobody dares touch. Managing orders, projects or hours, with users, permissions and a change history.
Service · web applications
Web-
sovellukset
When work runs on a spreadsheet, an inbox and one person's memory, it holds until it does not. A web application is the step where the process moves into a system several people can use at once, without anyone overwriting someone else's work.
From interface to database · one builder, clear ownership
[ 01 ]
Where it fits
W·02
Customer portals
The customer signs in and sees the status, the files and the invoices instead of asking by email. Less relay work for both sides.
W·03
Booking and scheduling
Calendar, capacity, confirmations and reminders. Double bookings are prevented at the database level, not by hoping in the UI.
W·04
Reports and dashboards
Numbers from several systems in one up-to-date view. No monthly hand assembly where somebody rebuilds the same table again.
[ 02 ]
One builder, no handover chain
In a normal project a designer draws, a developer implements, a third party ships it, and at every handover the reason something was done a certain way goes missing. Here there are no handovers.
That is also a limit, and I will say it plainly: one person does not build a system that needs a team of ten. If the project is that size, I say so during scoping and not halfway through.
What this fits well: a bounded problem with a clear owner and a measurable outcome. What it does not fit: a project where the requirements are still open and there are five decision makers.
[ 03 ]
What is under the surface
The interface is React and the server Node.js, but those are choices rather than convictions. What sits under them matters more: a database that will not let an impossible state through.
Rules that must hold live in the database: uniqueness, referential integrity, constraints. A check in the interface is a convenience, not a guarantee. A browser can be bypassed, the database cannot.
The application ships with its code and does not lock you to me: it runs on an ordinary stack, lives in your repository, and the next developer can pick it up.
Stack
[ 04 ]
How a project runs
01
Scoping
Who uses it, what they do, and what costs the most time in the current way of working. The result is a bounded first version, not a wishlist. Free of charge.
02
First version
The narrowest thing that is genuinely usable. It goes into use with real data, because demo data reveals nothing.
03
Driven by use
The next features are decided by what actually chafes in real use, not by what was guessed in the kickoff meeting.
04
Handover
Code, environments and backups in your name. Maintenance from me if you want it, but not because there is no alternative.
[ 05 ]
Common questions
Could off-the-shelf software be enough? Often it can, and if it is, I say so. Custom work pays off only when a ready product forces you to change what already works for you, or when the licence cost passes the cost of building.
What does it cost? The first version is priced as a bounded scope after the scoping call. There is an hourly rate for continued work, but a project does not start on an open-ended hourly bill.
Who owns the code? You do. The repository, the credentials and the environments move to your name, and you can change developer without the application being held hostage.
What if we also need a mobile app? The same codebase bends to React Native, so mobile does not mean a second project from scratch. Still worth doing only once the web side is in use.
Which step chafes
Tell me what is done by hand today and who does it. The scoping call settles whether it is worth building, buying ready-made, or leaving as it is.