← Portfolio Case Study

Accommodation MVP — room finder for construction crews in Germany

Klient: Construction company sending crews to Germany (anonymized) Czas: A few days
Next.js 14TypeScriptTailwind CSSResendVercelmonteurzimmer.deGeocoding

Before

  • The client had eight automation ideas at once and almost no internal systems
  • Finding rooms for crews was manual, repetitive, and dependent on many criteria
  • After the sales conversation, the lead went cold — another follow-up would only add friction
  • It was unclear whether accommodation data could be extracted and ranked reliably

After

  • Deployed MVP on a custom subdomain: kwatery.arturmrowicki.pl
  • 172 structured listings from one query, including geolocation and contact data
  • Filters: price, distance, crew size, kitchen, fridge, washing machine, parking
  • Editable German inquiry template + safe test sending through Resend
  • A live proof and reusable sales asset for construction companies operating in Germany

Live MVP: kwatery.arturmrowicki.pl

Context

The lead came from OLX: a Polish construction subcontracting company working in Germany, around 20 people, highly variable jobs and almost no structured internal systems. In one conversation, eight possible automation areas appeared: German contractor acquisition, crew database, timesheets, documents, invoices, website updates, project estimates and accommodation search.

Instead of pricing the whole mess, I picked one narrow module: finding rooms close to a construction site. It was the best MVP candidate because it had a clear input, clear output and measurable value: less manual clicking, faster contact with room owners and a better chance of finding cheaper rooms than through generic booking portals.

Why Accommodation

The client needed lodging for crews working in Germany. The criteria were concrete: up to 25-30 EUR per person per night, rooms for 2-3 people, up to 30 km from the site, kitchen, fridge, washing machine and parking for a van as a strong plus. This is not a generic hotel booking case. It is a typical operational problem for companies sending people into the field.

The key decision was not to build a "platform". The MVP had one workflow: enter construction ZIP code and crew size, get a ranked list of nearby matching listings, select offers and generate a German inquiry.

The Turn

After two good conversations, the lead suddenly stopped replying. Before that, replies came within minutes; after the summary, nothing. The diagnosis was uncomfortable but useful: the path to start was too long, the conversation surfaced too many risks, and introducing a paid consultation after initial price acceptance could feel like a step backwards.

In that state, another "just checking in" would not help. The better move was to build proof: instead of saying it could work, send a working link.

Data Recon

The source was monteurzimmer.de, a German portal for worker accommodation. The site was surprisingly machine-readable: results were server-rendered and the HTML contained structured listing data.

The most valuable piece was a hidden block with listing data: name, email, phone, WhatsApp flag, street, ZIP code, city, geo coordinates, price, capacity and amenities. One query returned 172 listings. Because the listings had coordinates, the MVP could calculate real distance from the construction site instead of showing a random search result order.

Solution

First came a fast Python demo: ZIP code, crew size, price filter and an HTML report. Then I turned it into a deployed Next.js MVP so the output was not a script but a product link.

1. Search by construction ZIP code

The user enters a German ZIP code, number of workers, maximum price per person and maximum radius. The app fetches listings, geocodes the construction location and ranks results by haversine distance.

2. Operational criteria, not hotel criteria

For this buyer, a pretty room matters less than kitchen, fridge, washing machine and parking. The MVP marks every listing with criteria badges, so the user can quickly see which rooms make operational sense for a construction crew.

3. German inquiry template

After selecting listings, the user gets an editable German message template. That removes another manual step: not only "find the rooms", but also "write to them in a reasonable way".

4. Safe test sending

A public demo must not spam real listing owners. Sending through Resend is locked to test mode: the full flow can be demonstrated, but messages go to a test address, not to accommodation providers. That is a product safety decision, not just an implementation detail.

Result

The client did not come back. That is part of the story, not something to hide. But the work did not vanish: it produced a deployed MVP on a custom domain and a repeatable sales asset for the whole segment of companies sending crews to Germany.

The main result was a live proof. The next client in this niche does not need a verbal explanation that accommodation search can be automated. They can open the link, enter a ZIP code and walk through the flow.

Next Steps

  • send from the client's own domain after SPF/DKIM setup,
  • dedicated inbox for replies from accommodation providers,
  • qualification questions in the email: parking, invoice, minimum stay, availability date,
  • more sources beyond monteurzimmer.de,
  • AI-personalized inquiry text per listing and crew requirements.

Takeaways

This case shows when an MVP makes sense: not when you build a small version of a huge platform, but when you isolate one costly process and turn it into a working tool. The scope is small, but the result is real: form, data, filters, contact flow, test sending, deployment and a custom domain.

The second lesson is sales-related: when a lead goes cold, pressure rarely helps. Working proof helps more often. And if that proof is useful for a whole segment, its value does not depend on one client's answer.

Have a similar problem?

Describe it in your own words — a short conversation gathers context, Artur delivers a quote in 48h.

Describe the problem