The First Feature I Built Wasn't for Users — It Was for Salvage Yards
U-PRO Build Journal — Episode 3
Episode 2 ended with a question I didn't expect to be asking myself right after finishing a multi-tenant database migration: now that the foundation was in place, what was I actually going to build on top of it first?
I'd assumed the answer would be something obvious. U-PRO is a shop-floor system for auto repair garages, so the natural first move, the one every generic inventory tool already does, would be something like "list your parts, search your parts, track how many you have left." Safe. Expected. The kind of feature nobody would ever ask "wait, why did you build that first."
That's not what I built. The first substantial feature I shipped once the multi-tenant foundation was ready was something for a much narrower slice of the business: salvage vehicle intake, and a specific method for figuring out how much each individual part harvested from a wrecked car is actually worth. If you don't work in this industry, that probably sounds like an oddly specific place to start. It was. And the reason I started there says more about who actually shows up first to try a new tool than any amount of market research would have told me on its own.
The problem nobody else was solving
A salvage yard, or a repair shop that also deals in used parts, doesn't buy inventory the way a typical parts retailer does. A retailer buys individual, itemized units — this bolt costs this much, this filter costs this much, each purchase has its own clean price tag. A salvage operation buys whole wrecked vehicles, usually for a single lump sum, and then has to take that one number apart into dozens or hundreds of individual components — an alternator, a set of doors, a working transmission, a windshield — each of which will eventually be sold separately, at its own price, whenever a buyer needs exactly that part.
That creates a genuinely awkward accounting problem that most inventory software simply doesn't touch: if you paid one lump sum for an entire vehicle, what did any single part inside it actually cost you? You can't just guess, and you can't just record "free" or "zero cost" for everything except the first part sold, which is the kind of shortcut that quietly destroys the accuracy of your margins the moment you try to look at real profitability per part. You need a real, defensible way to split one purchase price across many different outputs of wildly different value — an engine and a cracked side mirror did not cost the same amount to acquire, even though they came out of the same purchase.
This is a solved problem in accounting — it's the same category of question a company faces when one manufacturing process produces several different products from a single batch of raw material, and has to decide how much of that shared cost belongs to each output. But it isn't a problem general-purpose inventory software bothers to solve, because most of the businesses buying that software don't have it. A typical auto parts store buys individual units at individual prices. It has no reason to ever ask "how do I split this one purchase into fifty different cost bases." Salvage yards ask that question constantly, and as far as I could find, nobody building software for this space had actually built a real answer to it. That gap is what U-PRO's first substantial feature went after.
What the feature actually does
The mechanism I ended up implementing is a version of what's formally called the relative sales value method — an accounting approach for splitting one shared cost across multiple outputs based on how much each output is worth relative to the others, not based on some arbitrary equal split. The allocation follows value, not guesswork, and not an even split that would nonsensically assign the same acquisition cost to an engine and a mirror just because they both came out of the same car.
Building that logic correctly meant more than writing one calculation and calling it done. Real salvage intake doesn't behave the way a clean textbook example does. A vehicle that arrives, gets fully catalogued in one sitting, with every sellable part identified up front and nothing reclassified later, is closer to the exception than the rule. The feature had to handle the messier, more realistic version of that process — not just the tidy version that looks good in a demo.
Making the split concrete
It's worth walking through a concrete number, because "relative sales value method" sounds more abstract than the underlying idea actually is. Say a wrecked vehicle's parts add up to a hundred units of sellable value once everything is catalogued and priced. The engine alone might account for forty of those hundred units, a transmission and a set of body panels make up most of the rest, and dozens of low-value odds and ends — trim pieces, small sensors, a cracked mirror — round out the remainder at a fraction of a percent each. Whatever share of that total value a part represents is the share of the purchase cost it absorbs: the engine carries forty percent of the cost, the cracked mirror carries almost none.
The part that made this genuinely difficult to build wasn't the arithmetic — dividing one number proportionally across many parts is not, on its own, hard. The harder question was what to do about the fact that a salvage intake record is rarely final the moment it's created. A part gets marked unsellable after someone inspects it more closely and finds damage that wasn't obvious at intake. A part gets added to the record days later, once someone's had time to go back through the vehicle a second time and catalogue something that got missed the first pass. The obvious answer is to recalculate every other part's share each time the catalogue changes, since the "total sellable value" the split is based on just moved. I deliberately didn't build it that way. The total value estimate for a vehicle gets locked the moment disassembly actually starts — not editable afterward, no matter how many parts get added or reclassified later. Every part's cost gets computed once, against that frozen total, at the moment it's catalogued. Whatever gap opens up between that frozen estimate and the messier reality of how the vehicle actually gets picked apart — a part that turns out worthless, one nobody predicted at intake, ordinary rounding — never gets spread back across parts that were priced, and quite possibly already sold, earlier. It gets absorbed by the vehicle's last remaining line item, the scrap value, when the vehicle is finally closed out. That's where the actual engineering effort went: not writing a recalculation loop, but designing a system where nothing already priced ever has to be reopened, while the books still land exactly on the purchase price in the end.
Why I built this before anything more obvious
I want to be honest about the order of operations here, because on paper it looks like a strange prioritization call. Generic inventory tracking — search, quantity counts, low-stock alerts — is the feature almost every prospective customer would recognize and expect immediately. Salvage cost allocation is a feature that only matters to a specific subset of the market, and it's genuinely more complex to build correctly than basic inventory tracking is.
I built it first anyway, for a reason that has less to do with feature planning theory and more to do with what a very early, pre-launch product actually needs: a reason to exist that a generic competitor can't easily copy. Basic inventory tracking is table stakes — every piece of shop-management software already does some version of it, and building a slightly better version of an existing thing isn't a compelling reason for a skeptical shop owner to switch tools mid-year. A defensible, accounting-correct way to cost out salvage vehicle parts, on the other hand, was something I genuinely could not find anywhere else in this market when I looked. That's a much narrower audience, but it's an audience with a real, specific, currently-unsolved problem, and solving it first gave U-PRO something to point to that wasn't "we also do the thing everyone else does, but slightly nicer."
There's a version of early-stage product thinking that says you should always build for your largest addressable audience first, because that's where the growth is. I think that advice is right for products that already have some baseline of trust and adoption to build on. It's less right for a product with zero customers and zero reputation, where the more urgent question isn't "how do I reach the most people" but "what can I show a skeptical first customer that they can't get anywhere else."
What it cost to build it this way
None of this was free, and I don't want to tell it as though prioritizing the harder, narrower feature was an obviously correct call with no downside. It took real time — time that a more conventional roadmap would have spent on the features every single customer would touch on day one, like basic search and stock counts. Every week spent on the accounting logic for salvage allocation was a week the more universally useful features weren't getting built.
I made that trade consciously. It meant that for a while, U-PRO was a product that did one narrow thing very well and a lot of ordinary things not yet at all — a strange, lopsided place to be in the first weeks after the architectural foundation was finally in place. It's the kind of imbalance that only makes sense if you're confident the narrow thing is worth more, strategically, than the breadth would have been at that exact moment. I was confident, but confidence isn't certainty. What I had was a bet that a small number of demanding early customers with a real, underserved problem would matter more, this early, than a slightly better version of a feature every competitor already offers.
That same trade-off — depth over breadth, narrow-and-hard over wide-and-easy — is one I'd end up revisiting more than once as the product grew, not always with the same confidence I had that first time. The salvage feature paid for itself in the sense of giving the product a real reason to exist. It also meant everything else was later than it otherwise would have been, and that trade-off was about to become impossible to ignore.
What I'd tell a shop owner who asks "why does this matter to me"
If you don't run a salvage operation, none of this might sound like it applies to you, and for the basic version of using U-PRO, it doesn't have to. But I think the reason this feature came first says something worth knowing even if you'll never touch the salvage allocation screen yourself: it tells you what kind of problems this product is built to actually solve, versus which ones it's just checking a box on.
Any inventory tool can tell you a count is low. Very few can tell you, correctly, what an individual part sitting in your storage actually cost you to acquire, when the honest answer requires real accounting logic instead of a placeholder number. That's a small detail most shop owners will never look at directly. It's also exactly the kind of detail that determines whether the profit-per-job numbers this system eventually shows you are numbers you can trust, or numbers that look plausible but quietly assume every part was free until proven otherwise. I'd rather have built the harder, less visible thing correctly first, and let the more visible features catch up afterward, than have shipped the visible features early on top of a cost model I knew was wrong.
A narrow feature, and a wider question left open
Salvage allocation solved a real, specific problem for a real, specific type of customer. It didn't solve the much more basic question every shop — salvage yard or not — was going to ask within their first five minutes of actually using the product: can I get this thing running fast enough, and reliably enough, that it doesn't cost me more time than it saves? That question doesn't get answered by any single feature, no matter how well built. It gets answered by how quickly the rest of the product could be built around this new foundation, and that's the pressure that shaped everything that came right after.
This is Episode 3 of the U-PRO Build Journal. Episode 2 covered the decision to build U-PRO as a shared-database, multi-tenant system rather than giving every shop its own dedicated infrastructure. Episode 4 picks up the thread this episode leaves open: building something this specialized takes real time, and that pressure is exactly what pushed the next major change in how this product got built — delegating real engineering work to AI for the first time.