hilmi.Let’s talk
Hilmi H.
Let’s talk

A little more about me

Curious mind.
Practical
hands.

I’m Hilmi. I like building software that makes a complicated process feel clear.

Explore how I think Product thinking.
Hands-on engineering.
Choose a portrait of Hilmi
Hilmi sitting on a studio stool in a navy shirt and white trousers
Hi, I’m Hilmi.
Hilmi wearing a navy shirt and glasses
Same person. Another angle.

Two frames. One human.Select 01 or 02 ↗

Based in Indonesia. Working remotely.7+ years across product, code & production

01 / The person

The whole picture.
And the small details.

I’m an Indonesia-based remote full-stack software engineer with 7+ years of experience building and improving web products.

I work across requirements, architecture, backend systems, frontend interfaces, integrations, deployment, and production support. That range helps me see how a decision in one part of a product affects the people around it.

02 / The thinking

Every feature has
a bigger story.

Pick a request. Open a step.
See the questions I bring to the work.

What are we building?
The request

“Let people book online.”

Availability → reservation → confirmation

01

Start with availability.

Before adding a booking button, I ask what can be booked, when it is available, and which rules change the price.

A clear set of booking rules

02

Connect the reservation.

The interface, availability data, and reservation state need to agree. I account for expired sessions and competing requests along the way.

One connected reservation flow

03

Close the loop.

I trace confirmation back to the reservation, then check what the customer and operator see when a booking succeeds—or needs attention.

A useful outcome for both sides

The request

“We need to accept payments.”

Order → checkout → reconciliation

01

Define what is being paid.

I start with the order, price, currency, and lifecycle. A payment should belong to a clear business record from the beginning.

An order with an explicit payment state

02

Handle the in-between.

Checkout can succeed, fail, or be abandoned. I plan those paths and use verified provider events to update the payment state.

A checkout flow with failure paths

03

Make the result dependable.

Repeated notifications should not repeat a business action. I check how payment results reach the order, the customer, and administration.

Consistent records after payment

The request

“Our team needs a dashboard.”

People → handoffs → visibility

01

Find the real handoffs.

I map who does the work, what information they need, and where a task gets stuck. Those handoffs shape the dashboard.

A shared picture of the workflow

02

Give the work a clear state.

Assignments, uploads, and reviews need visible ownership. I connect the steps so a team can tell what is ready and what is waiting.

Work that is easy to pick up

03

Surface what needs attention.

I focus on the information that helps someone act: a blocked task, a missing upload, or an item ready for review.

A dashboard that helps the team act

See the projects behind this perspective

03 / The tools

The right tool.
For the real problem.

Explore my stack by what it helps me do.

Explore tools by purpose

Where people meet the product.

Interfaces and application foundations that fit the workflow, from the first screen to the admin tools behind it.

  • Laravel
  • PHP
  • React
  • Next.js
  • Inertia
  • Livewire
  • Filament

A dependable source of truth.

Structured data and connected APIs that keep different parts of a product working together.

  • MySQL
  • PostgreSQL
  • Supabase
  • REST APIs

The services around the software.

Payments and communication woven into the product’s lifecycle, including the paths that need a retry or a human decision.

  • Stripe
  • PayPal
  • HitPay
  • Midtrans
  • Xendit
  • Brevo

From a working build to real use.

Deployment, background work, and storage that support the product after its first release.

  • Cloudflare
  • DigitalOcean
  • Object storage
  • Queues
  • Process managers

A useful capability, with a clear job.

AI integrations when there is a concrete use case, with attention to how the result is checked and used.

  • OpenAI APIs
  • Anthropic APIs
  • Gemini APIs

04 / The collaboration

Remote by default.
Present in the work.

A few habits that make working together feel straightforward, wherever we are.

Discuss a project
01

I write things down.

Decisions, tradeoffs, and next steps stay visible, so the work can move without everyone being in the same meeting.

02

I ask about the workflow.

What happens before this screen? Who picks up the work next? Those answers are part of building the right feature.

03

I prefer small, testable releases.

A useful increment gives us something concrete to check, discuss, and improve before the next decision.

04

I’m honest about the unknowns.

I explain what is clear, what needs investigation, and which tradeoffs affect the product.

05

I stay involved after launch.

The first successful screen is one milestone. Production support and feedback help the product keep working for the people using it.

Now, your side of the story.

Clear communication. Practical engineering.

What are
you building?

Let’s talk about it Tell me the idea, the challenge, or the next step.