URBANKIT/STUDIO
    Sign inFREE · NO SIGNUP
    URBANKIT/STUDIO · EST. 2026 · ONLINEFREE · BROWSER-ONLY · NO TELEMETRY · OPEN SOURCE
    01 · About

    Better tools for the people who shape cities.

    UrbanKit Studio is a small workshop of free tools for planners, municipal staff, and community organizers. The workflows you don’t want to do, made fast enough to forget.

    Founded2025
    BasedDallas–Fort Worth, TX
    StatusIndependent · one engineer
    Free Forever

    The mission

    The work of running a planning department is administrative. You mail the notices. You buffer the parcels. You deduplicate owner addresses and print them onto Avery 5160 sheets that almost never align on the first try. None of this is glamorous. All of it has to happen before anything bigger can.

    UrbanKit Studio exists to compress that overhead. The tools here are free, run entirely in your browser, and require no account. Small municipalities, solo practitioners, and neighborhood associations can use them without filing a budget request or signing a vendor contract.

    Departments without seven-figure GIS budgets deserve the same tools as the ones that have them.

    The cities that need help the most have the least money to buy software. Free, browser-only tools cut past licensing, IT review, and procurement. That friction keeps useful technology away from the people doing the work.


    Why this exists, the long version

    P / 01

    Free, with no asterisks.

    No subscription, no “starter tier,” no email wall. Every tool here works for the first user the same way it works for the thousandth.

    P / 02

    Built around real workflows.

    Each tool addresses a specific pain planners encounter: public hearing notice radii, CSV-to-label conversion, parcel lookup against arbitrary ArcGIS REST services. Not a generic GIS suite.

    P / 03

    Your data stays on your machine.

    CSV files, GeoJSON parcels, generated PDFs all process in the browser, never uploaded. No ingest, no warehouse, no analytics on what you’re working on.

    P / 04

    Growing, deliberately.

    The roadmap is open-data integrations, demographic and transit visualization, and tools that help residents engage in the planning process. No feature inflation.


    Who built this

    UrbanKit Studio is a one-person project. Built and maintained by Leo Yong, a fullstack software engineer based in Dallas–Fort Worth, Texas.

    Urban planning isn’t Leo’s day job. It’s closer to a long-running fascination: regional transit, zoning reform, architectural design, the unglamorous infrastructure that holds cities together. He follows the field daily (transit openings, comp plan updates, fights over single-stair reform) and built UrbanKit Studio to contribute back. It started as a small itch and grew into something that makes someone’s Tuesday a little easier.

    Every feature ships from a real workflow somebody has. Feedback, especially the awkward, specific kind, is the only way the project gets better.

    Visit Leo’s personal site


    How the atlas gets built

    Atlas endpoints come from four sources. Some are published openly by county GIS departments. Others turn up through ArcGIS Hub catalog searches when a county has put a layer online but never advertised it. State portals (Illinois ILGISA, California CAL FIRE, Oregon ORMAP) aggregate them by region. The rest arrive through the /contact form from planners who already know where their county hides them.

    Every entry gets checked by hand before it goes live. A human runs a GET against the layer’s /query?where=1=1&resultRecordCount=1&f=json, confirms the URL resolves, checks that the response includes parcel geometry, and reads the searchFields list to label which fields the public can query against versus which are system-generated, locked, or empty. Field shape is the part that breaks silently; a counted, working response is the only proof that the schema we publish matches what the endpoint returns today.

    Re-verification runs on a cadence. Weekly for the top-traffic counties: Cook IL, LA CA, Maricopa AZ, King WA, Broward FL. Monthly for everything else. Each entry carries a lastVerified date; an entry flips to stale once that date is older than sixty days. The full breakdown of sourcing rules, query templates, and the contributor pipeline lives on /methodology, shipping in a follow-up.


    Where we sit in the landscape

    Regrid is a commercial nationwide parcel API with paid licensing, broader and deeper than what UrbanKit indexes. The right answer for production GIS work and parcel-data analytics. Not free, and not what this site is.

    County-direct portals are authoritative, free, and the canonical source. But each county runs its own URL, its own field schema, its own viewer interface, its own login pattern. Hard to find, harder to query consistently across more than one jurisdiction at a time.

    UrbanKit Atlas is a curated, free directory pointing at the public REST URLs counties already publish. We don’t sell the data, and we don’t proxy it. We point to it and explain how to query it. The value sits in the curation, in labeling which fields expose owner names versus PIN-only, and in the workflow tools (Parcel Lookup, Radius Notice) that consume those URLs without an account or an upload.

    A planner running one public hearing a quarter does not need a Regrid seat. A neighborhood association mailing 40 owners inside a 500-foot buffer does not need one either. They need the URL their county already publishes, a label that says which field holds the owner name, and a tool that takes both and returns a CSV. That is the slot UrbanKit fills.


    What goes in the atlas, what doesn’t

    S / 01

    What we publish.

    Verified-public ArcGIS REST layers: FeatureServer or MapServer endpoints that return parcel geometry without authentication. Each entry shows its field schema, a sample query, and the date it was last verified.

    S / 02

    What we don’t publish.

    Anything behind authentication stays out. So does anything we can’t verify against the live endpoint, and anything that exposes personally-identifying data the county doesn’t already make public. We don’t republish private homestead exemptions, for example, even when a county leaks them. In practice, the entries that get pulled are layers that swapped a FeatureServer for a tile cache, layers that started requiring a bearer token, and layers a county quietly retired without a redirect. Every removal carries the date and the reason in the source data.

    S / 03

    Last-verified discipline.

    The date on every atlas entry is when a human ran a real query against the endpoint and confirmed the response. Automated freshness checks would scale better, but they also produce false-positive “still live” entries when a county silently changes field shape. So we check by hand.


    How this stays free

    Free, ad-supported. Google AdSense slots appear on tool and atlas pages, never inside the data tables or the interactive controls. The revenue pays the hosting bill, the domain renewal, and the engineering hours that keep the atlas re-verified and the tools current. Paid tiers, vendor deals, and gated data are off the table for as long as ads cover the line.

    One affiliate link lives on the CSV to Labels page: a tagged Amazon link for Avery 5160 label stock. Disclosed inline on the page, optional for the user. We use the same stock ourselves when we need labels.

    What we don’t do: no data sales, no telemetry, no email harvesting beyond the optional newsletter (one or two emails a month, unsubscribe in one click). The newsletter is the only optional data we ever collect.