Politik: How Three First-Time Founders Hit #2 on the App Store

Politik is an iOS app that puts American politics in one place: who represents you, how they vote, where their money comes from, what is moving through Congress, and an AI that explains any of it in plain English. Three first-time founders had the idea, and we built it with them in under three months. It launched with 4,000 users on day one, hit #2 on the App Store, held a 4.7 rating and stayed on the charts for three weeks.

This is the story of how that happened. It covers what the founders needed, what we built, what the launch looked like and what we think other first-time founders can take from it. Everything about Politik here comes from the project itself. Where we explain why we made a call, we say so, because that part is our reasoning and not a log of events.

If you are a founder with domain knowledge and no engineering background, this is the closest thing we can show you to a proof. If you want the short version of the project, it lives on the Politik case study page.

Politik was started by three international relations majors who had just spent a summer on Capitol Hill. Their names are James VandeHei Jr., Charlie Stallmer and Chris Brophy. They had worked close enough to Congress to see how hard it is for a normal person to follow what it does.

The problem they described to us was specific. To understand one vote, you check a vote record on Congress.gov. For the money behind a candidate, you open a campaign-finance site. For context, you watch cable news. For the spin, you scroll social media. And the bill itself is written in language nobody outside a law office can read. Nothing connects, every source has an angle, and most people give up. The founders pointed to one number that stuck with us: 68% of Americans cannot name their own representative.

Their goal was to build one place that explains all of it to a 20-year-old in thirty seconds. That is a clear product sentence. It names a user, a time limit and a job. Founders who can say their product in one sentence like that are far easier to build for than founders with a long list of features.

They also arrived with two things that matter more than code. They had the domain knowledge, so they knew which questions people actually ask about government. And they had a distribution plan, so they knew where their first users would come from. What they did not have was a line of code, and they wanted to launch in under three months.

When a founder has never shipped software, the instinct is to treat the build as a black box. You hand over a spec, wait, and hope. We think that is the wrong shape for the work, and Politik is a good example of why.

The three founders knew politics and we knew how to ship an app. Neither side could do the other's job. So the work had to be a conversation, not a handoff. Here is what we believe a first-time founder needs from the team building their product:

• Someone to cut scope. A founder who knows the subject deeply wants to include all of it. A good partner decides what the first version is.
• A product opinion, not just engineering. Choosing what goes on the home screen is a product call, and it decides whether the app works.
• A fixed finish line. Under three months was the constraint from the first day, and every decision was measured against it.
• Plain explanations. A founder who understands why a choice was made can defend it later, to users, press and investors.

If you are weighing whether to start with a smaller first release, our MVP development guide covers how to decide what goes in and what waits. Politik is a case of that thinking applied hard. The first release was a real, broad app, but it was broad around one idea, a single feed that answers a few questions well.

We began with a two-week product sprint with the founders. The job was to map every source people currently juggle to understand politics, and then decide what one home feed should answer.

The feed came down to three questions: who represents me, how did they vote, and what is happening in Congress right now. Those three questions became the spine of the app. Everything else in Politik hangs off one of them.

Why do a sprint like this before writing code? This is our reasoning, and it applies to most first builds. The most expensive mistake in a new app is building the wrong thing well. A sprint with the people who know the subject is the cheapest way to avoid that. It forces the founders to say what matters, and it forces us to say what we think will not fit in the first release.

It also gives a first-time founder something they rarely get: a shared picture of the product before money goes into engineering. The founders left the sprint knowing what the home screen was for. That clarity carried through the rest of the build.

A politics app has a trust problem that most apps do not. If a user thinks the app leans one way, they leave, and they tell their friends why. Design is the first place that trust is won or lost.

We designed a light, editorial interface with a red-to-blue gradient brand system. The rule was that no party color dominates any screen. That sounds like a small visual choice, but it is a product decision. A user opening the app should not be able to tell from the colors which side the makers are on.

The same thinking explains why the app leans on official sources. A product that explains politics earns trust by showing where each fact came from, and by not adding an angle of its own. Our view is that in a category full of strong opinions, a calm interface and a visible source are the product's most useful features.

Light and editorial also fit the audience. The founders were building for people in their twenties who are not going to read a dense dashboard. The screens needed to read like something you could finish in thirty seconds.

Under the interface, Politik is a data product. The build included a data layer on Congress.gov, the Google Civic Information API and OpenStates. Its job is to take any zip code or GPS location and resolve it to a district, its senators and its House member.

That one capability is what makes the home feed personal. A user does not browse a list of every member of Congress. They open the app and see their own representatives first.

Behind the app is a Node.js backend with PostgreSQL and a scheduled ingestion pipeline. The pipeline pulls Congress.gov, campaign-finance and state data into a single feed, so the whole picture lives in one place and stays current.

Here is why we think this design matters beyond Politik. Any app that combines several outside sources has the same hidden problem: the sources change on their own schedule and in their own format. If the app fetches data live from each source every time a user opens a screen, it is only as fast and as reliable as the slowest source. If a scheduled job collects and normalizes the data first, the app talks to one database that you control. The screens stay fast, and a broken upstream source becomes a problem you fix in the pipeline and not a problem every user sees. That is the reasoning behind an ingestion pipeline, and it is why we reach for one whenever a product depends on data it does not own.

Joining sources into one feed also does something for the user that no single source can. It connects the vote to the money to the bill. That connection is the reason someone uses Politik instead of ten open tabs.

The AI feature in Politik is a chat assistant called Politik AI. It explains any bill, vote or process in plain English. The example from the project is a good one: "What is the filibuster?" answered in one screen instead of one afternoon.

The assistant is grounded in official data. It runs on OpenAI models, and it works from the same Congress.gov and state data the rest of the app uses. Here is our reasoning on why that matters.

A general chatbot answers from whatever it learned in training. For a question like what a bill does or how a member voted, that is risky, because a confident wrong answer in a politics app does real damage. Grounding means the assistant is given the relevant official records and asked to explain those, instead of recalling from memory. The answer can then point back to a real source, and a user can check it.

For a politics product this is close to a requirement, and for most AI features inside a real product we recommend the same approach. The model does the explaining. Your data does the knowing. If you want the technical shape of that pattern, our guide on how to build an AI chatbot walks through retrieval and knowledge bases in detail.

A single answer to a single question does not bring people back. Politik needed reasons to open the app again, and the build included several.

• A real-time legislation tracker. It shows progress timelines from introduction through committee to floor votes, plus chamber-balance and votes-held visualizations.
• An interactive US map. Users tap a state and explore it.
• Executive branch profiles in order of succession, and Supreme Court justices with ideology indicators.
• Daily "How would you vote?" polls. A small prompt that gives a reason to return.

Notice the mix. The tracker and the voting records are reference features, the kind a user needs when they have a question. The map and the daily poll are habit features, the kind that bring someone back when they do not have a question at all. A product that explains politics needs both, because most people do not wake up wanting a civics lesson.

We would also point out what is not on the list. There is no social network, no comment section and no feed of opinions. The app stays on explaining, which keeps it consistent with the nonpartisan design and keeps the build inside the time limit.

Politik shipped to the App Store in under three months, built with React Native and Expo on the front end and Node.js with PostgreSQL behind it. Launch day brought 4,000 users. Within a week the app hit #2 on the App Store, and it stayed on the charts for three weeks. It holds a 4.7 rating.

Press followed. Axios ran a feature story headlined How college students with no coding experience built the Politik app. Fox 5 ran a TV segment. Politik was also a guest on SiriusXM for a radio interview.

The founders also took the app to campuses. Politik now runs campus launch events, starting with 100+ students at the University of Denver, and the team is building toward Politik 2.0.

The founders sum up the build in one line: "Together, we completed the app in under three months."

We want to be careful about what we claim here. A good product, a clear audience and a distribution plan all contributed to those numbers, and the founders brought the last two. What we can say is that the app was finished and focused when launch day came, and that a launch like this punishes a product that is confusing or slow.

Politik is one project, and one project is not a rule. Still, a few of the decisions behind it apply to almost any founder building a first app. These are our conclusions, drawn from how this build went.

Pick one job and say it in a sentence

The founders wanted one place that explains politics to a 20-year-old in thirty seconds. Every feature either served that sentence or did not get built. If you cannot write your own version of that sentence, write it before you talk to any developer.

Bring what you know that we do not

The founders brought domain knowledge and a plan for reaching users. We brought the engineering and the product structure. Neither is optional. A technical team cannot invent your insight into a subject, and you cannot invent the shipping side without one. If you are not technical, our guide to launching an MVP as a non-technical founder lays out what to prepare.

Treat data you do not own as a pipeline problem

If your product depends on outside sources, collect them on a schedule and serve your users from your own database. This is the single design choice we would copy into most data-driven apps.

Ground your AI in your facts

Let the model explain and let your data decide what is true. In a category where wrong answers cost trust, this is the difference between a feature and a liability.

Set the date early

Under three months was a constraint from the start. A deadline that is real forces the scope conversation, and the scope conversation is where most first builds are won.

Politik started with three people who knew a subject and had never shipped software. They left the first conversation with a plan, and under three months later they had an app on the App Store that hit #2.

If you have a clear idea, a way to reach your first users and no engineering team, that is the kind of project we like. We run the product sprint with you, design the app, build the backend and ship to the App Store. You can see the full project on the Politik case study page, or read how we think about early releases in our MVP development guide.

We build apps like this. If you have one in mind, book a free strategy call.