Remolk
Trailer rental where software, payments, telemetry and physical operations have to work as one system.
A physical business modeled as a digital product.
The interesting part of Remolk isn’t that it has a website. It’s that customers, reservations, payments, physical trailers, GPS devices, telemetry, operational rules and business decisions all have to behave like one coherent system.
It looks like a simple rental. It isn’t.
From the outside, renting a trailer looks like a catalog, a date and a payment. But the real system has to represent something that exists in the physical world: a concrete asset, available or not, that gets handed over, moves, comes back and can generate exceptions.
The product has to add up for the customer and for whoever operates the business. That’s where software stops being “screens” and becomes a system.
Not just “the one who builds the site”.
I participate as CTO and partner. The work isn’t just implementing screens: it’s deciding what system the business actually needs, in what order to build it, and what moves the needle for the business and the user. The system is in production: real payments, real devices and a rental flow you can walk through end to end.
I was in charge of all of Remolk’s development end to end: architecture, code and product decisions.
The product lives between two worlds.
Each layer has to stay aligned with the next — from customer intent to what is physically happening with each asset.
The product lives between the digital state and what is physically happening with each trailer. This is a system-level view, not low-level architecture documentation.
The decisions that hold the system together.
The browser doesn’t decide the price
If the amount to charge travels from the client, the client can change it.
The server recalculates the price from scratch before creating the charge and ignores whatever the front sends. Obvious — until the first discount feature gets implemented on the wrong side.
One payment, one rental — never two
Payment confirmation can arrive through two different paths at almost the same time. If both create the rental, it duplicates.
Both paths converge on the same idempotent operation. The second one to arrive creates nothing: it recognizes the work is already done.
The return has to be verifiable
“I already returned it” is a user claim — and the trailer becoming available again and the charge stopping both depend on it.
The return requires a photo taken on the spot, validated automatically before it counts, and the close-out is authorized server-side. The user can’t free the asset on their own. The photo is analyzed automatically with AI to verify it matches the asset before the rental can close — AI used where it replaces a person reviewing photos one by one, not as pitch decoration.
The physical world has state too.
In a demo product, changing a database value may be enough. In Remolk, the system represents real physical assets: that changes how you think about correctness, state, visibility, reliability and payments.
When a product represents physical assets, “what the system says” and “what is happening out there” have to stay aligned. That kind of problem forces you to think beyond the frontend: states, payments, devices, rules and operations all become part of the same product.
Choosing the device was a product decision too.
The system needed a trailer parked on the street to communicate its status without anyone having to ask: available, rented or out of service. That turns what looks like a purchase into a technical constraint — how many distinct signals the unit has to be able to emit, and therefore what control capabilities the device needs.
I owned that whole end: finding suppliers, requesting and comparing quotes, reading the datasheets, checking each model against what the product needed to show, and negotiating terms. The conclusion wasn’t “the cheapest one”: the most economical unit couldn’t represent all the states the business needs to distinguish, and choosing it would have made a feature that was already decided impossible. It’s the kind of decision you can’t delegate to a supplier: you have to read the datasheet and the product roadmap at the same time.
I built the prototype of the status module —weatherproof enclosure, solar power and the lights— and validated it against a real rental before committing to a batch.
Deciding what to build first.
Why mobile-first?
The rental is decided and managed standing next to a trailer, from the phone. Desktop exists, but the phone is what matters.
What belongs in the MVP?
Only the path that enables a real end-to-end rental: find, pay, pick up, use, extend and return. Everything off that path was left out, even if it looked good in a demo.
Advance reservations or instant rental?
No calendars, no future bookings. You rent what’s available now. A calendar promises something the physical world can’t always deliver.
How is availability represented?
System state and the real state of the asset have to match: the trailer is freed when the return is confirmed, not when the user says they did it.
From prototype to real operation.
The next learning no longer comes from another demo. It comes from real users, payments and trailers. The system is functional and the next stage is validating how the product behaves once it enters operation. I don’t claim business metrics that don’t exist yet.
From an owned fleet to a network.
Today Remolk rents its own fleet. The next step changes the nature of the product: selling trailers with the system already installed. The owner uses it as an ordinary trailer and, when they’re not using it, lists it from the web: it joins Remolk’s pool, gets rented like any other, and the owner receives a share of what it generates.
That turns a fleet business —which grows by buying assets— into a network that grows when someone else buys the asset. And it shifts the weight of almost everything already built: availability stops being an internal fact and starts depending on a third party; return verification stops protecting only the company and starts protecting the trailer’s owner; telemetry stops being an operations tool and becomes the evidence you account with to someone who put in their own asset.
It’s the direction, not a promise with a date. What matters is that the decisions of the last few months —price resolved server-side, verifiable returns, asset status signaled on the street— are exactly the ones that make that step possible without rebuilding the system.
Product ownership
Turning business operations into product decisions.
Systems thinking
Understanding software, payments, devices and physical assets as one system.
Prioritization
Deciding what has to exist before real use and what can wait.
Integrations
Working around payments and device telemetry, not isolated UI.
Business judgment
Optimizing for a functioning rental business, not technical novelty.
Real-world constraints
Building toward users who will actually pay and assets that actually move.
A team of one person plus agents.
Remolk was built with an AI-assisted flow, end to end: every change starts as a ticket with acceptance criteria, an agent implements it, a pull request opens with a preview environment, it goes through an automated review that ranks findings by severity, QA runs on the preview, and only then does it merge. The merge deploys to production on its own.
My role there isn’t writing every line: it’s defining what gets built, in what order, what has to be true to accept it and what can never break. The hard part of working with agents isn’t getting them to write code — it’s having the judgment to decide which code deserves to exist and to catch when what they did is well written and badly thought out.
Does your product also have to survive off-screen?
Payments, people, operations, hardware or real rules completely change how you have to think about software.