Building PTC Cargo's logistics software

A cargo operator needed software that matched how the business actually worked. What we built, and how we got from a vague brief to a working product.

The App14 team1 min read

The short answer

PTC Cargo came to us without a specification, which is normal. The founder's summary afterwards was that we turned vague instructions into software that just works.

The situation

Cargo and freight operators run on knowledge that lives in people's heads and in messages. Where is the consignment. Who signed for it. What did we agree with this customer last time.

That works at one scale and stops working at the next. The failure is rarely dramatic: it is a slow accumulation of phone calls, disputed deliveries, and time spent reconstructing what happened.

The constraint

The brief was not a specification. It was a description of how the business worked and what kept going wrong, which is what almost every honest brief looks like.

A supplier who needs a finished requirements document before they can start is passing that work back to you. Turning an operational description into a buildable scope is the job.

What we built

Software matched to the operation rather than to a generic freight template. The specifics belong to the client, but the shape is one we build often: the operational record in one place, the people who need it able to reach it, and an admin view for the office.

How day one worked

This project is a good illustration of why we spend the first day on scope rather than on architecture.

  1. Day 1

    Kick-off and scope

    We go through your goals, your users, and the one job the app has to do. Everything that is not that job goes on a version-two list.

  2. Days 2 to 3

    Design

    Screens, flows, and the look of the thing. You review and revise until you sign off. Nothing gets coded until you have.

  3. Days 4 to 10

    Build

    Front end, backend, accounts, notifications, admin dashboard. You see working builds as they land rather than a reveal at the end.

  4. Days 11 to 12

    Test and fix

    Real devices, real data, edge cases. This is where most of the unglamorous work happens.

  5. Days 13 to 14

    Submit and launch

    Store listings, screenshots, privacy details, and submission to the App Store and Play Store. Then 30 days of support while your first users arrive.

The conversation on day one was not about technology. It was about which single part of the operation, if fixed, would remove the most friction. Everything else went on the list for later.

What happened

They understood exactly what we needed. They turned our vague instructions into beautiful software that just works. The knowledge is remarkable.
Amal Shad, Founder, PTC CargoAmal ShadFounder, PTC Cargo

Where a sprint has limits in logistics

Case studyFast Flyer Transport: launched in 10 daysDelivered ahead of the fourteen-day window.

Run a logistics operation?

Tell us what you're trying to build and we'll tell you honestly whether a 14-day sprint is the right way to do it.

Free. No commitment. Just a conversation.

About the author

The App14 team · Design and engineering, Appetite Studio

App14 is the 14-day app sprint run by Appetite Studio, a London-registered design and engineering studio. We design, build, and ship production iOS and Android apps in two weeks, at a published fixed price. Everything we write here comes out of work we have actually delivered: the prices are our real prices, the timelines are our real timelines, and the limits are the ones we genuinely hold to.

Our articles are drafted with AI assistance and reviewed by the App14 team before publication. The prices, timelines, delivery record, and client outcomes described are our own.

Read next