Before You Build
Web AppShut Down

MyCity

MyCity was a GovTech SaaS platform for local governments to collect resident ideas, feedback, and civic conversations.

View original story

Product snapshot

What it was

MyCity let local governments ask for opinions, gather resident feedback, run conversations, and access admin features around civic input.

Who it was for

local governmentsmunicipal departmentsresidents participating in civic feedback

Problem / value

Turn scattered resident ideas into a managed civic engagement workflow for city authorities.

Core workflow

  • Collect resident ideas
  • Run civic conversations
  • Provide analytics and admin tools to local authorities
  • Turn public feedback into city-improvement workflows

Product form

web appGovTech SaaScivic feedback platform

Pricing model

Planned government subscription model. The founder reported three one-time sales totaling EUR 20,000 to EUR 30,000.

What happened

Summary

MyCity grew from a successful civic side project into a GovTech SaaS, but shut down after the team found that municipalities lacked the buyer workflow the product required.

Outcome

Shut down. The case is best read as a buyer-workflow validation warning for institutional SaaS and civic products.

Demand signal

The issue was not that residents had no interest. The gap was on the buyer side: municipalities did not already have a process for handling incoming ideas, so the platform had no repeatable workflow to improve.

Distribution issue

Bottom-up citizen demand did not become a reliable government sales channel; direct sales produced a few deals but did not prove a repeatable subscription path.

Timeline

  • 2013: The team launched MyMurmansk, a public idea map that collected almost 200 ideas in 48 hours.
  • Platform phase: The team turned the concept into MyCity, a commercial SaaS for local governments.
  • Sales strategy: The founders tried bottom-up citizen-created sites, expecting public momentum to pressure city authorities.
  • Early deals: Direct sales produced a few one-time sales, including a version launched in Tromsø, Norway.
  • Shutdown: The team gradually lost momentum after realizing the target buyers lacked a process for working with incoming ideas.

Before you build

Why it matters

Many B2B and GovTech products serve users who are not the economic buyer. MyCity shows why builders must validate the paying organization’s process, success metric, and renewal reason before turning interest into a platform.

Primary check

Validate the paying buyer workflow before building admin software around user-side enthusiasm.

Relevant if

  • Your users and buyers are different groups.
  • You are selling to government, education, enterprise, or another institution.
  • Your product asks the buyer to create a new internal process.

Less relevant if

  • Your buyer is also the daily user and already owns the workflow.
  • Your product improves a process with a clear budget and existing operational owner.

Pre-build tests

  • Ask the buyer to describe the exact current process and owner for handling the problem.
  • Define one customer success metric the buyer agrees matters before building dashboards.
  • Run a manual pilot and confirm the organization acts on the incoming feedback.
  • Require a renewal or expansion condition before treating a first sale as validation.

Transferable lessons

  • Interview paying buyers before building admin features for them.
  • Define customer success metrics before the first serious sale.
  • Test whether bottom-up user activity creates buyer urgency in this specific market.
  • Sell one narrow workflow before positioning as a broad civic engagement platform.

If you build this today

Start by proving one municipal workflow, one success metric, and one renewal-worthy use case before expanding the civic engagement platform.