I don't start with technology.
I start with people.
Most problems that look like technology problems are actually people and process problems in disguise. That's the belief that shapes everything I do.
Rachman Setiawan Amir
Digital Systems Consultant
My background is in Information Systems — a field that taught me early on that technology never exists in isolation. It always exists alongside people and processes. And when those three elements are misaligned, even the most technically sound system will fail.
Early in my career, I worked in IT Support. It wasn't the role I had planned for, but it turned out to be one of the most valuable experiences I've had.
I wasn't just fixing computers. I was watching how people actually worked — where the friction was, where time was being lost, and where small inefficiencies quietly compounded into bigger problems.
That experience gave me a perspective that most developers never get: the view from inside an organization, before any system is built.
The turning point came when I worked on a system that was actually used.
Not just deployed. Not just launched.
Actually used — by real people, in their daily work.
I watched someone's workload genuinely reduce because of something I had built. That felt different from anything before.
It made me realize that the goal was never to write good code. The goal was to build something that genuinely helped someone work better.
Since then, that's been the standard I hold every project to: not "does it work technically?" — but "does it actually help the people using it?"
I believe that technology should serve people — not the other way around. That means every solution I build starts not with a framework or a tool, but with a question: What is actually going on here, and what do the people involved really need?
"The wrong solution — no matter how well-built — is still waste."
Every engagement I take on is grounded in the same thinking framework — one I've carried since my Information Systems training and refined through years of real work.
Before anything else, I try to understand who is involved. Not just their job titles — but how they actually work, what slows them down, and what they're trying to accomplish. The goal is to see the system through their eyes before suggesting how to change it.
Then I look at how work actually flows. Not how it's supposed to flow on paper — but how it really happens, day to day. Where the workarounds are. Where things quietly break. Where people have adapted around a system that doesn't quite fit.
Only after that does technology enter the conversation. What tools already exist? What can be optimized? And if something new needs to be built — what should it actually do, and for whom? Technology is the answer to a question, not the starting point.
This sequence matters. Reversing it — starting with technology — is how most digital projects end up unused.
The name Crafted By Rach is intentional. I chose the word "crafted" — not "built," not "developed" — because it carries a different kind of meaning.
Craftsmanship implies attention. It implies care for the person who will ultimately use what you make. It implies that the process matters, not just the output.
When I work on a system, I try not to think only as a developer. I try to think as the person who will sit with that system every single day — and ask whether it's actually making their work easier.
Technology should not complicate work. It should simplify it.
Systems should not just function. They should support people.
And software should not just be built — it should be crafted.
If this way of thinking resonates — let's have a conversation.
Not about what to build. About what problem you're actually trying to solve.