Build journal
How many of us are there?
In my small company, I sometimes play developer, salesperson and customer support.
A company brochure can make an organisation look wonderfully structured.
There are services, skills, processes, and sometimes a presentation that looks like it belongs to a much bigger company.
Then you look behind the scenes.
And ask a funny question: how many of us are there, exactly? 😄
Starting a small digital business can mean talking to the customer, designing the interface, building the application, sending the invoice and answering “it doesn't work” yourself.
I know that mixture well. It's part of building KAMIT.
A business doesn't necessarily start with a team
We often picture entrepreneurship with offices, meetings, employees and organisational charts.
In the beginning, it may be one skill, a computer and a problem you think you can help somebody solve.
The early steps aren't glamorous: explaining the offer, listening, drafting a proposal and keeping promises.
Then you have to deliver.
Then explain, train, correct and support what you shipped.
The technical work is not the whole business. Sometimes it isn't even the hardest part.
Too many hats
Versatility is a strength at first.
Knowing how to code helps you estimate projects. Understanding design improves presentations. Communication skills help you talk to clients.
But the roles compete.
When I'm coding, I'm not prospecting.
When I'm answering messages, that feature isn't getting finished.
When I'm writing a commercial proposal, the product I want to launch has to wait.
It's not just time management.
Switching between roles carries a mental cost.
What the client doesn't see
Consider a website project.
The client sees the pages, photos and buttons.
Behind them are requirements, architecture, content, revisions, search visibility, hosting and pre-launch checks.
After delivery, there may still be changes or issues to resolve.
All of this needs to be scoped, understood and priced properly.
I explore similar questions in The tiny SaaS dream.
A profitable project isn't merely one that got paid. It's one where you understand the work, risk and ongoing responsibilities.
When should you get help?
It's tempting to answer, “As soon as you're busy.”
But hiring or subcontracting requires money, instructions, quality checks and time too.
Before delegating, you may need to document how things work.
What's the expected result? What can be handed over? How do you share access securely? Who speaks to the customer if something goes wrong?
These questions aren't as exciting as a new project.
But they matter if you don't want to remain the bottleneck for everything.
The real goal
My ambition isn't to wear as many hats as humanly possible.
It's to build a business that creates value without requiring every spare minute of my attention.
I'm not there yet.
For now I'm experimenting, building systems and learning between client work and personal ideas.
Sometimes I'm the developer.
Sometimes I'm the salesperson.
Sometimes I'm the person reminding the developer what the salesperson promised.
The funny thing is that all three are in the same room. 😂