Ship features not plumbing

The quarter you spent on data plumbing was not on your roadmap

Time to first call under ten minutes, so the feature is the work and the integration is not.

Propalt Team · For PropTech platforms

Every property feature starts with the same unglamorous phase. Read the docs, get a key, work out the auth, write a client, handle the edge cases in the response, and only then start building the thing your users actually asked for. That phase does not appear in the pitch to your product owner, but it eats real weeks, and it eats them before any user-facing value ships. The data plumbing is invisible on the roadmap and expensive in the calendar.

There is a fair objection here: some upfront integration work is unavoidable, and pretending otherwise is how projects slip. Agreed. The goal is not to make the plumbing free, it is to make it short and predictable, so the estimate you give is the estimate you hit. Time to first call under ten minutes is not a marketing number for its own sake. It means the integration is a morning, not a sprint, and the quarter is available for the feature.

Time to first call under ten minutes

The path to a first successful response is deliberately short. Sign in, get a key, and you have 500 free credits per month to test against real data rather than a sandbox that behaves differently in production. The OpenAPI 3.1 spec describes every endpoint, so your editor can generate types and your tests can validate against the contract from the first call. There is no reverse-engineering of undocumented fields and no guessing at what a response looks like when a property is missing a value.

Copy-paste request samples are provided in ten languages, so whether your platform runs on TypeScript, Python, Go or something else, the first call is a paste and a key, not a translation exercise. There is no client library to install, version and wait on for updates. It is the raw OpenAPI 3.1 spec plus working samples, which means you integrate directly against a documented REST API and keep control of your own client. The fewer layers between your code and the endpoint, the fewer things break when either side changes.

The timings above are illustrative of a straightforward integration. Your mileage depends on your stack, but the order of magnitude is the point.

Where the quarter goes instead

When the integration is a morning, the arithmetic of the quarter changes. The weeks you would have spent on auth, clients and response handling go to the interface your users see: the search that feels instant, the property page that loads its full picture in one view, the comparison that used to need three tools. Those are the things your roadmap is judged on, and they are where your team's time is best spent.

The integration is not the feature. It should not cost what the feature costs.

MCP tools for Claude and ChatGPT extend the same principle to your AI features. If your product surfaces property intelligence through an assistant, the endpoints are already exposed as tools, so you are wiring behaviour rather than building connectors. The pattern is consistent across the whole surface: the data access is solved, documented and fast to adopt, and your engineers are left to build the part only they can build.

Let the integration be a morning so the feature can be the quarter.

Try the Ship features not plumbing → · propalt.ai

Data is drawn across 29 million England and Wales properties from 8 authoritative UK registers plus the Propalt intelligence layer. Figures shown are illustrative. This article is general information for platform teams.