Why we exist
Cities still run permitting on PDFs, a rigid patchwork of systems, tribal knowledge, and long email chains. The result is bottlenecks, frustrated applicants, and not enough homes, or anything for that matter, getting built. The country is roughly 5 million homes short, and permitting delay is one of the biggest brakes on closing that gap: UCLA found that a 25% reduction in approval time increases housing production by a full 24.6%. Fewer review cycles convert almost directly into more homes. Govstream.ai exists to pull that lever. Our mission is to make building easier, cheaper, and much faster by turning permitting into one continuous, conversation-driven workflow, guiding every step from the first zoning inquiry through final inspection. The North Star is same-day construction permits, down from the 9 to 12 months a review can take today.
What we're building
Strip permitting to its essence and you find three things tangled together: a long-running conversation between the builder and the city, a workflow running on both sides of the counter, and a thousand decisions that need support. The incumbents digitized the transactions and stopped there. We rebuilt the three strands as one system, and we call it Conversational Workflow for Permitting. It's the only permitting system that:
- guides the builder at every step and holds their full context, the chats, the emails, the documents, the permit history, across the weeks of an application's life;
- gives staff decision support across every role and discipline involved in review, without ever substituting for their judgment;
- and manages communication and translation between the city and the builder: code language on one side, plain language on the other.
Underneath, that conversation produces facts: what the applicant is building, where, how tall, on what kind of lot. AI agents work at the edges and turn the messy world into proposed facts: one draws them out of the conversation, one classifies uploaded plan sets and extracts values from them, one queries the city's GIS. Every proposed fact passes a validation gate before it's committed to an event log with full provenance. The city's rules live in House, our domain-specific language with its own compiler and type checker, and every new fact re-evaluates them deterministically: what just became required, what's satisfied, what's still missing. The answer drives the next question in chat, the next tool call, or the next item on a reviewer's screen, and that cycle runs continuously, on every channel, for every application.
Applicants experience this as the Permit Center: one guided conversation, across web and email, that gets them to a complete, review-ready application on the first try. Staff experience it as the Review Center: decision support that shows what's complete, what fired, and why, with the rule and the code section behind every answer. And one boundary holds everywhere: the system determines what is required, never what is approved. Judgment stays with the city's staff, and everything we build gives them more time and better information to apply it.
We also run the same cycle on ourselves. We onboard a new city by having agents write its configuration test-first, with the writer barred from grading its own work, which is why each city costs less to bring live than the one before. And we improve a live city by replaying its real historical permits through the system, fixing the configuration wherever its answers disagree with what the city's reviewers actually decided, and locking every miss in as a permanent test. Running those two loops for real cities is the heart of this job.
The role
Every city we sign starts the same journey: from signed contract to a live public permitting portal that residents, builders, and developers use every day. As our first Customer Success Engineer, you own that journey end to end. And launch is not the finish line: our growth depends on early customers who are not just happy but visibly and vocally successful: cities that can show meaningful, demonstrable progress in making permitting simpler and faster, and that say so to their peers. You own the results behind that story.
This is a founding position in the fullest sense. Today our engineers take cities live themselves, and everyone stays involved, from the CEO to marketing to the engineers, because every onboarding teaches us something and we adjust. But we've reached a critical mass where the work needs an owner: someone who builds a repeatable methodology, keeps communication with our cities consistent, and designs the automations behind it with focus and care. That owner sets the pace of the company's growth, because a signed city creates no housing and no revenue until it launches. By early 2027 we expect 15-20 cities on the platform. The platform is ready for them; this role is how they get live.
The job combines three kinds of work that almost never appear in one role:
- Hands-on technical work, with serious leverage. Little of this is manual. You run an onboarding through Claude Code, our MCP tools, and the automation we've already built: agents pull and reshape the permit history, draft the House configuration, and run the test suites, while you direct the work, review what comes back, and handle the parts that need a person. You can only trust that leverage if you could do the work yourself: you read the SQL and the rules the agents wrote, catch what they got wrong, and debug from logs and traces when an answer comes out wrong.
- Customer and project ownership. You are the city's owner at Govstream.ai. You model their permitting process in their language, sit with their staff to validate it, run the weekly check-ins, keep every open project with an owner and a date, and make the launch calls, including telling a city that wants to go public that it isn't ready yet.
- Automation and systems building. This part takes a builder's mindset and real judgment: you decide which pieces of the work are worth turning into systems, prototype them, test them against a real onboarding, and work with engineering to scale what works into the product. Each city should take less manual work than the one before it, because the systems you built along the way carry more of the load.
You'll also be laying a foundation. You are our first Customer Success Engineer, not our last, and the team we grow will run on the methodology, the tooling, and the standards you build. The people who join after you will follow the playbook you wrote and use the systems you designed. That makes this work foundational to our growth model, not just to your own accounts.
Most jobs make you pick one of those three kinds of work. This role only works if you love all of them, and very few jobs let you practice all three at once with this much riding on the outcome.
Every engagement builds toward proof. The city's approved process becomes configuration, and you test that configuration against their own historical permits, measuring how many of the corrections reviewers once had to chase would now be caught at intake. In one city, first-submission completeness went from 22% to 67%. In another, 39% to 70%. From there you run the rollout, from a guided first run in a test environment through invited real applications to public launch, and then permit type after permit type until the portal covers the city.
In any given week
You might:
- drive agents through the technical core of an onboarding: point one at years of permit records and check what it pulled, push a configuration change through Claude Code, and trace a wrong answer back to a GIS layer that returned nothing;
- sit with three permit reviewers who disagree about when a drainage plan is required, walk a real case through the model until the disagreement surfaces, and leave with a decision;
- notice that a failing scenario can only pass if you weaken what it expects, and take it to the city as a question instead, because their rule is the specification;
- use the city's own permit history to answer a question their leadership is asking, and catch the chart that is technically correct but misleading before it goes out;
- write the backtest report a city reads, walk them through the evidence permit by permit, and end with the questions that drive the next round of improvement;
- walk an invited group of builders and homeowners through their first live applications, and debrief what confused them;
- invent a clearer way to show a permit center manager what their process requires, try it in Thursday's session, and bring what worked into a design conversation with our product team;
- turn Tuesday's manual step into a script or an agent workflow, and work closely with our engineers to build it into the product for the next city;
- work through the next city's rollout strategy with the founder and the team, debate what the last city taught us, and rewrite the playbook where it needs it;
- run the weekly check-in, and raise the problem before the city does.
What you'll bring
The technical bar is real: this role does engineering work every day, and we interview for it.
- You work with AI agents and check their work. Most of this job runs through Claude Code against our MCP tools and the onboarding automation we've built: you specify tasks well, read results critically, and know which steps must stay human.
- You read and write logic like code: boolean conditions, thresholds, type systems, and edge cases. Nobody knows House before joining, and we look for people who pick up a small new language in a day.
- You are fluent in SQL and comfortable moving between database engines: a city's permitting system usually runs SQL Server, and our platform runs Postgres. And you write working Python, because reviewing an agent's extraction takes the same fluency as writing it yourself.
- You spend real time in a terminal, and bash, git, and jq are daily tools rather than occasional ones.
- You can own a data integration end to end: you get data out of systems nobody designed to share, reshape it, load it where it needs to go, and verify it actually landed.
- You debug from evidence. When something breaks, you read the logs, the traces, and the API payloads, and you can tell "our rule is wrong" from "the data layer returned nothing."
And the bar on the customer side is just as real:
- You turn messy documents into specifications. Given a submittal checklist, a zoning table, and a portal walkthrough, you produce a defensible statement of what the city requires, and you name the ambiguities instead of smoothing them over.
- You can run a business process discussion and get a decision, and you stay credible while you do it: when something is our interpretation rather than the city's confirmed rule, you say so.
- You write clearly for two audiences: a note a city official reads once and acts on, and an internal log a colleague could pick up cold.
- You report the truth under pressure. You check your own numbers before a customer does, and the status you report stays accurate when the demo is Thursday.
- You own accounts over quarters, keep progress visible, and make the hard calls.
- You're deeply curious, a self-starter with intrinsically high standards, and an optimist.
- And your colleagues and your cities like working with you.
Valuable, but not required
- Experience in permitting, planning, local government, construction, architecture, civil engineering, or computational design. Anyone who has lived either side of a permit ramps up much faster.
- Implementation or delivery experience in govtech or vertical SaaS (Accela, Tyler, OpenGov, or similar).
- GIS (ArcGIS, QGIS, spatial SQL).
- JavaScript, for the reports and internal tools we prototype.
- Elixir. Our platform is Elixir and Phoenix; reading it helps.
You might be
- a forward-deployed or solutions engineer who has done real configuration and data work, not just demos;
- an implementation engineer from a regulated domain (permitting, insurance, healthcare billing, tax) who already treats the customer's rules as the specification;
- a data engineer who likes customers;
- a GIS analyst or planner who codes;
- an architect, civil engineer, computational designer, or construction pro who codes and has sat on the applicant's side of a permit;
- a permit tech or plan reviewer who moved into technology.
Whatever the background, the same three things hold: you can build, you report what the data actually says, and cities trust you in the room.
How we evaluate
Our process is practical. Expect exercises built from real public city material: turning a permit checklist into a specification, triaging failing test scenarios, finding the trap in a permit data export, and a working session in Claude Code on a real configuration change. We care much more about how you think and check your work than about any specific line on your resume.
How we work
We're a small, high-performance team: transparent, fast, ownership-driven, and deeply focused on creating value for cities and residents. Everyone builds and ships. We work in the open, collaborate closely, and review each other's work, and what we optimize for above all is ownership and speed. We're heavy users of AI, Claude in particular, but humans still own every review, and we genuinely value the craft. We avoid bureaucracy and waste and pursue excellence in everything we do.
Traction
We're live in Bellevue and Louisville, with active pilots in 8 cities, and we're well funded and at an inflection point in our growth. By Q4 2026 and into Q1 2027, we expect to have 15-20 cities on the platform, positioning us for a strong Series A. Our ambition is to solve permitting across thousands of cities, not just in the US but globally. We're early enough that you would be shaping not just your own function but the company itself.
Details
- Location: Remote-first, but US-based only. Greater Seattle Area preferred, not required.
- Compensation: Competitive salary and meaningful early-stage equity.
- How to apply: Write to careers@govstream.ai with a short note on something you've built that you're proud of, and a link to it if you can share one.
Govstream.ai is an equal opportunity employer. We welcome applicants of every background and do not discriminate on the basis of race, color, religion, gender, gender identity or expression, sexual orientation, national origin, disability, age, or veteran status.