From analysis to infrastructure: owning the whole freelance process
On the e-commerce, congress and corporate websites I built as a freelancer, analysis, design, software and technical infrastructure were all mine. In this note I describe what carrying the whole process alone makes easier, and what it makes harder.
01One owner, several hats
In my freelance work I rarely had a single role. I built corporate websites for companies and agencies, event websites for congresses and sales-oriented e-commerce websites. In each of them, understanding the need, designing the interface, developing the application and setting up the technical infrastructure were parts of the same responsibility. I carried all of it out individually, from start to finish.
At first I saw this only as workload. Over time I noticed it also gives you a perspective. When every stage sits with a different person in a team, some decisions get lost on the way as they change hands between stages. When one person carries the whole process, that loss shrinks, but other risks take its place. In this note I want to look at both honestly.
02Not underestimating analysis
For someone owning the whole process, the easiest mistake is to rush through analysis and jump straight into design or code. The moment a solution takes shape in my head, it is tempting to start building it. Yet in freelance work the client's need is often not fully clear in the first conversation.
So in every job I first tried to define the scope, the user journey and the content structure. On an e-commerce site, the user experience and the underlying operation need to be designed together. On a congress site, presenting information in a clear structure comes first. On corporate sites, the core is explaining clearly what the company or agency does and what value it offers. Each type starts with a different question, and analysis, to me, is simply asking that question well.
03Design and development at the same table
The most concrete benefit of one person doing both design and development is being able to think about whether a design decision is buildable while still drawing it. While designing an interface, I can weigh at the same time how it will be coded, where each piece of content will come from and how the page will behave on different screens. This reduces the "this cannot be built this way" kind of back and forth between design and implementation.
I felt this especially on congress websites. On event sites, the organization of content and the navigation experience directly affect each other. Running design and software through the same information structure helped pages stay both readable and easy to maintain. On corporate sites too, developing information architecture, visual interface and implementation together makes the organization's identity on the web more consistent.
When one person carries the whole process, decisions do not get lost changing hands, but there is no second pair of eyes to question them.
04The invisible part: technical infrastructure
What the client sees is mostly the interface. But the technical infrastructure that keeps the site running is part of the work too, and the responsibility is mine again. Because it is invisible, it is the part most exposed to neglect. It is not enough for a site to work properly on the day it is delivered; it also needs to stay understandable and sustainable afterwards.
My approach here is simple: plan the infrastructure as part of the work from day one, not leave it to the end. When interface, application logic and infrastructure are handled together, later patches become fewer. Especially in projects like e-commerce, where the operation reflects directly on the user, a solid structure underneath matters as much as the experience on the surface.
Being understandable to whoever opens the site after delivery, whether the client's team or a developer taking over the work later, is part of that sustainability too. That is why I try to set up an orderly structure and clear decisions before technical debt builds up.
05The limits of working alone
Owning the whole process has a weakness that should be stated plainly: there is no second person to question your decisions. In a team, the designer can catch the developer's assumptions and the developer can catch the designer's. Working alone, I have to build that check deliberately myself.
For that I tried to build a few habits. When I finish a stage, I come back to it after some time and look at it through the eyes of a different role. When I finish the design I try to think like a developer, and when I finish the code I try to think like a user. I also care about using conversations with the client not just to get approval, but to test my assumptions. It is not a perfect method, but in a one-person process it at least reduces the blind spots.