I built a gas cost splitter. The formula was the easy part.

GasSplit started with a small question:

How much gas money should each person pay after a trip?

The calculation seemed straightforward:

Distance ÷ Fuel economy × Fuel price = Fuel cost

Divide that cost by the number of people, and you have a calculator.

My background is in digital marketing and SEO, and I’m building with AI assistance. A focused tool like this felt like a manageable project: a clear problem, a few inputs, and a useful result.

Then I started looking more closely at the decisions hidden inside those inputs.

Does “distance” mean one way or the entire trip? Does the driver pay an equal share? What if someone knows their car model but has no idea what MPG means? And once you have the answer, how do you explain it to your friends?

Those questions shaped GasSplit more than the formula did.

An illustrative trip: 300 miles, 30 MPG, and $3.60 per US gallon, plus tolls and parking. Four people share the $48 total.

A correct calculation can still produce the wrong answer

One of the most useful changes came from the distance input.

An earlier version asked users to choose how the distance should be interpreted before entering a number. The options made sense when I thought about the calculation. Looking at the actual page, the sequence felt backwards.

I wanted to type the distance I knew first.

We changed the flow to:

Distance
[ 150                         mi ]

☐ Include return trip (distance ×2)

When the return option is selected, the interface shows the interpretation:

150 mi each way · 300 mi total

That last line matters. Someone could enter the total distance of a round trip and then accidentally double it. The arithmetic would still be correct for the values passed into it.

The interface needs to make that mistake easier to notice.

GasSplit also accepts odometer readings from before and after a trip. That difference already represents the distance driven, so the return-trip option does not belong in that mode.

This became a recurring lesson: every input needs a clear meaning, and the result should make that meaning visible.

Small layout decisions were part of the explanation

I spent more time than expected on the “Car & fuel” section.

There was a “Find my car” action for looking up fuel economy. My first concern was alignment, but the more important question was where it belonged.

It helps answer the fuel-economy field. Placing it at the level of the entire section made that relationship less clear.

Other details kept surfacing:

• A save action and its browser-storage explanation occupied more vertical space than they needed.
• Dropdown arrows sat too close to their borders.
• A currency control appeared to offer only USD when opened.
• Moving a unit selector fixed one layout and left a square-looking control in another mode.

Individually, these were small issues. Together, they made a short form feel more complicated.

I began treating layout as part of the instructions. Putting a unit beside its number, placing help beside the field it supports, and keeping secondary explanations visually quieter all reduce what someone has to work out.

“Fair” needed a choice

Splitting a bill equally sounds simple until you ask whether the driver should contribute.

For some groups, everyone pays. For others, the passengers cover the fuel because the driver is providing the car and doing the driving.

I didn’t want the calculator to silently choose one arrangement and call it fair. GasSplit lets people choose whether everyone pays or only passengers pay.

Even a small example exposes details worth explaining. If a $35 cost is shared by three passengers, displaying $11.67 for each person totals $35.01. A breakdown of $11.67, $11.67, and $11.66 preserves the original total.

These details affect whether someone can look at a bill and understand it without another conversation.

Sharing the bill and sharing the product are different jobs

I initially found myself questioning whether “Copy bill,” an image export, and “Share” were redundant.

Thinking about what the user was trying to do made the distinction clearer.

Copying a bill helps someone paste the calculation into a group chat. Saving an image gives them a visual summary they can send. Sharing GasSplit recommends the tool to another person.

Those actions deserve different emphasis.

The result should first help someone communicate what each person owes. A smaller invitation to share the product can come afterward.

That also changed how I thought about the output. The useful result is more than a large number. It needs enough context for the people receiving it to understand where that number came from.

The same illustrative trip, presented as a breakdown the group can understand. Everyone pays, including the driver.

SEO research helped me ask better questions

Because of my background, I looked at competing calculators and the searches they appeared for.

Phrases such as “gas money” and “gas cost splitting among friends” helped me see the language around the problem. People may be looking for a calculation, but they may also be unsure how to split the cost or what is reasonable to ask a friend to pay.

That gave me a direction for explanations and guides alongside the tool.

It also tempted me to keep changing headings and adding more keywords.

I decided to be more cautious. A competitor’s ranking is useful evidence that a topic has demand; it does not tell me which sentence caused that ranking. I’ve kept some title changes as future experiments rather than treating every wording suggestion as an improvement.

For now, I want the content to explain the assumptions, show worked examples, and help people use the calculator correctly.

Working with AI made verification more important

AI helped me build and iterate, but several changes took more than one pass.

A proposed interaction was missed. A control behaved differently from what its code suggested. A styling change looked fine in one mode and awkward in another.

Automated calculation tests were useful. They could not tell me whether a dropdown felt cramped or whether the order of the fields made sense.

I now want every change to be checked at three levels:

1. Does the calculation still work?
2. Does the interaction make sense in the browser, including on a narrow screen?
3. Is the intended version actually live?

As a non-programmer, I’m learning that giving clearer instructions helps, but so does being specific about what counts as finished.

GasSplit is still early. I don’t have evidence yet that these changes improve conversion or retention. What I do have is a more explicit interface, fewer hidden assumptions, and a better way to review the next change.

I started by trying to answer “How much does each person owe?”

Building the tool has made me pay just as much attention to a second question:

Can someone understand and trust how we arrived at that amount?

If you’ve built a calculator or another small utility, what input looked obvious to you but turned out to need more explanation?

Disclosure: I used AI assistance to develop GasSplit and to help draft this post. The examples describe decisions and revisions from the project.

Comments

[Preetest Team]

Agree the formula is the easy part — the round-trip hint under the distance field is exactly the kind of detail that makes it usable. One thing I noticed on the live site: Cloudflare injects its Web Analytics beacon, but your CSP's script-src doesn't allow static.cloudflareinsights.com, so the browser blocks it. If you check Cloudflare's analytics, it's probably undercounting (GA via GTM is allowed, so that one should be fine).

Disclosure: we're the Preetest team (an AI website-testing platform by Yamama Software). Happy to run a full Preetest check on it and post the report here if you want — just say yes.