Din pålitliga taxi i Borlänge website

Abdullah Elmassri — Thu, 22 Oct 2026 15:21:00 +0000

The hardest part of a small-business website isn’t always the design. Sometimes it’s making sure the right website actually appears when someone visits the domain.

I’ve been building a website for Din Borlänge Taxi AB, a local taxi company. The goal was straightforward: help visitors understand the service, see pricing, and either call or send a booking request—without making them hunt for the next step.

That sounds like a frontend task. It turned into a useful lesson in routing and deployment.

Start with what a visitor needs to know

Before thinking about components, I considered the questions a visitor might have:

Do you serve my area?
What might the trip cost?
Can I book online, or should I call?
Is the information available in my language?

That shaped the site around a clear homepage, service and pricing pages, contact details, and a booking flow. Swedish and English support was part of the initial design rather than something to bolt on later.

The site uses React and Vite for the frontend. The booking and contact forms send requests to a separate Node API, which validates submissions on the server. This matters because browser-side checks can improve the experience, but they can’t be trusted as the only validation.

A custom domain isn’t the same as a published website

The domain had been verified, so I expected the taxi site to appear there. But when I checked the live domain, it showed a different app already in the project. The taxi site’s previous path returned a 404.

That exposed an important distinction:

Domain verification confirms that DNS points to Replit.
Publishing puts a particular project build online.
Routing decides which app handles a request to a given URL.

Those are separate steps. A domain can be verified while the site you intend to show is still not the one serving the homepage.

Give each app a clear route

This project contains more than one web app. Daylight, a personal productivity dashboard, already occupied the root route. The taxi website had been configured under /din-borlange-taxi/.

I wanted the taxi site to be the homepage without deleting Daylight, so I changed the route assignments:

Din Borlänge Taxi now uses /.
Daylight remains available at /daylight/.
The taxi API uses /taxi-api/api.

The separate API prefix avoids mixing taxi requests with the shared project API at /api. It also makes the route map easier to reason about: the homepage serves the taxi site, while its backend has its own namespace.

Keep the site base and API base separate

There was one subtle bug along the way. The app used a base-path variable both for API requests and for the client-side router. When I changed the API prefix, the router started treating /taxi-api/ as the website’s base route. The page loaded blank.

The fix was to make those two concepts explicit:

The router base controls which website paths the frontend recognizes.
The API base controls where form requests are sent.

They can look like similar strings, but they have different jobs. Keeping them separate made the app work at the root route while still sending requests to the dedicated API path.

Verify the whole path, not just the build

A successful build doesn’t prove the website is reachable at the intended URL. I checked the frontend build, the API tests, and the API health endpoint. I also opened the actual preview and caught the blank-page routing issue that a build alone would not have revealed.

That changed my definition of “done.” For a multi-app project, verification should include:

Does the expected homepage load?
Do secondary apps still load at their assigned paths?
Can the frontend reach its API?
Does the live domain show the intended build after publishing?

At the time of writing, the routing changes work in the project preview. The custom domain needs a new publish to pick up those changes.

What I’d improve next

Before relying on the site for real customer requests, I’d finish the owner-side workflow: ensure booking details are properly protected, notify the owner when requests arrive, and give customers clearer inline feedback when a form needs correction.

The main lesson from this build is simple: a website is not finished when its components render. It is finished when the right site, at the right address, can complete the action the visitor came to take.