Doorstep.ai — Making the invisible last 100 meters of delivery visible

The last 100 meters

Google Maps can get a delivery driver to a building. Then the certainty starts disappearing. Which entrance should they use? Where should they park? Which floor is the customer on? Did the driver actually reach the correct doorstep? And when a customer says a package never arrived, what does the delivery company actually know happened after the driver entered the building?

That final stretch is where Doorstep.ai operates. Doorstep builds location intelligence for the last 100 meters of delivery. Its technology uses sensors already available on a driver’s smartphone to understand what happens when conventional GPS starts losing precision, including parking, entering buildings, moving between floors, and reaching the final delivery location. When Doorstep came to us, the technology already existed. The harder problem was making people understand why it needed to exist.

Doorstep was not an existing relationship or a referral. They posted an opportunity on Contra. We applied. That led to a conversation with Yuri Choi, who walked us through the company, the technology, what they were trying to build, and where Doorstep wanted to go next. At the time, the website was largely centered around a video. The company was preparing for its next fundraising chapter and wanted a digital presence that could communicate the scale of what it was building. The initial ask looked like a website project. It quickly became an exercise in understanding a complicated technology well enough to explain it simply.

Invisible infrastructure

Most of us think package tracking is already precise. We can watch a delivery vehicle moving across a map. We receive notifications. Sometimes we receive a photograph. Then: Delivered. But the map usually understands the journey better than the destination. Conventional location systems are good at getting a driver to an address. They become considerably less useful once the driver parks, enters a building, and begins navigating the final meters of the delivery.

Doorstep describes this gap today as “Unreliable GPS. Failed PODs. Endless disputes.” The company says fraud and failed deliveries represent more than $10 billion in losses, while proof-of-delivery images can frequently be blurry, misleading, or lack sufficient context. Those are Doorstep’s published market estimates, but they illustrate the economic problem the company was attacking. The final 100 meters were not simply a mapping problem. They were creating operational uncertainty. And uncertainty eventually becomes money.

Almost everything interesting about Doorstep happened invisibly. There was not a new device for the driver to carry, not hardware we could photograph, not even necessarily a new workflow for drivers to learn. Doorstep’s SDK could integrate into an existing driver application and use sensors already inside the smartphone to understand movement where GPS becomes unreliable. The driver could continue delivering. Doorstep could observe what happened underneath. The better the technology worked, the less the driver needed to think about it. That is excellent infrastructure. It is difficult marketing. Our website had to make invisible technology visible.

The map knows the building. It does not know the doorstep.

Most of the website moved relatively quickly. The problem section did not. We kept coming back to it — different layouts, visual metaphors, city representations, relationships between maps, buildings, and destinations, levels of abstraction. Some iterations were visually stronger. Others were technically clearer. Very few did both. We were not stuck because we could not make a section look good. We were stuck because we had not found the simplest way to make someone feel the gap Doorstep was solving.

The problem was not really “GPS is inaccurate.” That is technically true but emotionally meaningless to most people. The more understandable version was: we know the package reached the address. We do not necessarily know whether it reached the door. Suddenly the problem became physical. A city becomes a street. A street becomes a building. A building becomes an entrance. An entrance becomes a floor. A floor becomes a doorstep. And between each of those layers, information disappears. That gave us a much stronger visual territory to work with.

If something moves, it should explain something

We structured the website around a deliberate sequence: Hero, Problem, Solution, Observability, Expansion / Platform / Dashboard, Engineering & Reliability, CTA, Footer. Each section had a job. The hero established the idea. The problem revealed a blind spot. The solution explained what Doorstep could see that traditional GPS could not. Observability showed this was not only about one package. The platform and dashboard showed what the data could become across a delivery network. Engineering & Reliability answered the question a serious technical buyer would ask: can we actually deploy this? The site became an argument: problem → understanding → technology → operational value → scale → technical confidence.

We did not want Doorstep to look like another logistics SaaS company with a dashboard floating above a stock photograph of a delivery van. The technology itself was spatial, so the design language became spatial too: maps, coordinates, architectural plans, buildings, city models, wireframes, grids, spatial layers, blueprint-style illustrations, and transitions between physical environments and their digital representations. One direction used a large three-dimensional city beneath an intense blue horizon. Another stripped the environment down into architectural line drawings. The latter looked almost like the city had been converted into something a machine could understand. That relationship between the physical city and its digital representation became part of Doorstep’s visual identity.

Doorstep is fundamentally about movement — approach, park, walk, enter, move vertically, reach a floor, find a destination, complete the delivery. Motion could become part of the explanation rather than something added afterwards to make the website feel expensive. Transitions could communicate scale. The city could become a building. The building could reveal another layer. A delivery journey could move from conventional GPS visibility into the environment where Doorstep begins providing additional context. If something moves, it should help explain something.

From one delivery to a network

Doorstep was not merely trying to produce a more accurate pin on a map. The information generated across the final 100 meters could become operational intelligence: last-100-meter analysis, ETA accuracy that separates parking time, in-building time, and dwell time, driver wayfinding for parking, entrance, and elevation, and delivery intelligence around failed deliveries, delays, and operational performance. A single delivery produces a location signal. Millions of deliveries produce a dataset about how the physical delivery network actually behaves.

Once Doorstep could understand individual events, the next question became what an operator could learn across the network. Instead of presenting Doorstep only as an SDK, we could show the operational layer above it. Where are deliveries failing? Where are drivers spending unnecessary time? Which buildings repeatedly create problems? Where are proof-of-delivery disputes happening? How does the final stretch affect ETA accuracy? The website needed to make the progression understandable: sensor → event → delivery → network → intelligence.

Beautiful storytelling could get someone interested. It could not get an SDK deployed across a delivery network. Eventually the technical questions arrive: hardware, devices, battery, integration, specialized scanners, scale. That is why Engineering & Reliability became its own section. Doorstep today says its SDK works across 99% of iOS and Android devices, including specialized Zebra scanners, requires no additional hardware, and is designed for minimal battery and memory impact. Credibility is not only explaining what is possible. You also have to explain why deployment is not going to become somebody else’s nightmare.

The project did not stop with a Figma handoff. We built the website in React, because much of the design existed between static frames: motion, transitions, layering, responsive behavior, timing, how illustrations appeared, how information revealed itself. A static mockup could show what Doorstep looked like. The browser had to show how Doorstep felt. Design and engineering could not behave like two departments passing files across a wall. The browser became the final design surface.

The company kept moving

We did not raise Doorstep’s funding round. Doorstep built the technology, company, customer relationships, pilots, and investor case behind that outcome. The chronology still matters. They came to us while repositioning ahead of their next fundraising chapter. We helped rethink how the company presented its problem, technology, platform, and technical ambition. In September 2025, Doorstep announced an $8 million seed round led by Canaan, with participation from Antler, Cercano Management, Cassius, and Sean Henry. Canaan’s Hrach Simonian joined the company’s board. The funding was intended to help Doorstep move from pilots toward broader production deployments. The website was one piece of a much larger company transition.

Doorstep today is significantly further along than the company we first encountered through Contra. The company says its technology now covers more than 160 million doors across every U.S. state, with its location intelligence powering millions of deliveries. It has expanded around predictive delivery intelligence and continued building machine learning, data, engineering, and forward-deployed capabilities. We were trying to create a visual and narrative foundation for a company whose product surface was going to keep expanding. The website could not only explain what Doorstep was. It needed enough room for what Doorstep might become.

We do not have reliable attribution data for traffic, conversion, or demo requests, so we are not going to manufacture them. What we did notice is that people started asking Doorstep who designed the website. People in Doorstep’s orbit reached out. Doorstep referred people they encountered back to us. In some cases, someone discovered NextGrid because they had first discovered Doorstep. We had designed something intended to make Doorstep memorable. The work ended up making us memorable too.

Taste is the scarce part

We started comparing later work against Doorstep — not aesthetically. Every NextGrid project should not have blue architectural drawings and animated cities. That would turn a design language into a costume. What became the benchmark was the relationship between story, taste, motion, product understanding, and engineering. Doorstep showed us what happened when those things were treated as one problem rather than five deliverables. The question on later projects became: are we understanding this company deeply enough to produce something this specific to them?

The involvement spanned repositioning, narrative, architecture, visual direction, problem visualization, spatial illustration, motion, observability and platform storytelling, engineering communication, prototyping, and React. We would not reduce the project to that list. Almost every item on it can now be generated faster than when we started the company. Twenty different hero sections can appear before lunch. Producing options is getting cheaper. Choosing is not.

The difficult part was deciding which options deserved to survive. Which visual actually explained the problem? Which one merely looked impressive? When did motion improve comprehension, and when did it become distracting? When did simplification make the story clearer, and when did it make it wrong? Those are judgment questions. For Doorstep, taste determined what someone should see first, what could disappear, where they should slow down, and what they should remember after closing the tab. We did not invent Doorstep’s sensor fusion, delivery network, or market. Our contribution happened at a specific moment in the company’s evolution. We helped make an invisible problem visible. And once people could see the problem, the technology had a much better chance of explaining itself.

Questions