Why make 36MDC

There are already several tools for mobile data collection. We have used most of them, and some of them for years. Building another one was not something we did lightly. Three reasons pushed us there, and they are the reasons 36MDC looks and behaves the way it does.

We were tired of hearing "we can't"

The tools we ran field projects on had a pattern. A reasonable request — a new field behavior, a cleaner image, an export the customer could actually use — would come back as "not on the roadmap," or as a one-off toggle that worked in isolation and never got smoothed into the rest of the product.

Some of this is just what happens to a platform that was good a decade ago and is still running. Features accumulate as temporary fixes, the edges stop lining up, and the camera code stops keeping pace with what phones actually produce. You end up with 2026 handsets sending 2016-grade images to the server.

We did not want to build a product where "we can't" was the default answer to a reasonable field-work ask. That has shaped how we pick dependencies, how we designed the field type system, and how we decide what goes into 1.0.

Your data should be yours

The obvious layer is the records themselves — the rows your team captured in the field should be exportable, in a sensible format, on your schedule, without a ticket. That part is table stakes.

The less obvious layers are where most field-work tools quietly fail:

Portable formats. Location data in 36MDC is stored as GeoJSON, not a proprietary blob. Records come out in shapes your downstream tools already understand.
Readable form definitions. A 36MDC form is a JSON document you can read. Field types are named ("text", "number", "gps") rather than numeric codes where 1 means text and 2 means number, and every property has a clear purpose. A form is a portable artifact, not a captive row in someone else's database.
Data sources that live where your data lives. Lookup lists can be sourced from your own SQL database instead of a CSV you remember to re-upload every quarter. The list of vehicles, sites, or staff stays in the one place it already lives.
Rolling deletion by design. 36MDC is a collection platform, not a storage platform. Records are deleted on a rolling schedule after they have been delivered downstream. That sounds unfriendly until you consider the alternative — field data piling up on someone else's servers, slowly becoming the single source of truth by accident, with no long-term strategy behind it. We would rather push teams to build that strategy early than let it drift.
Connectors out. Webhooks ship today. Direct connectors to common databases are on the near roadmap, so records can land in your warehouse or operational store without a middleman.

Owning your data means being able to use your data. Everything above is what that looks like once you take the claim seriously.

There is a gap in the market

Look at what a field team can buy today and you mostly see three shapes:

The large ecosystem. A data-collection module bolted onto a much bigger platform, priced for teams using the whole stack. Fine if you are all in; heavy if you just need to capture records.
The legacy tool. Good a decade ago, still running, still supported. Works, but is showing its age in the ways described above.
The general-purpose form builder. Free or cheap tools that were never designed for the field. Fine for a signup sheet, unfit for an inspection route with no signal.

36MDC is meant to sit in the space none of those three cover — a modern, focused field-data platform that treats offline, data portability, and field ergonomics as starting points rather than afterthoughts.

Where this goes

The reasons above are the ones that put us on this road. They are also the ones we hold ourselves to as we build — every field type, every default, every export format gets checked against them. If any of this sounds like your situation, the best way to follow along is through the rest of the blog on this site, or by getting in touch at hello@36mdc.com.