Fashion PLM vs Spreadsheets: When to Make the Switch
I ran my own brand on spreadsheets for years, and for a long time they were the right call. Here's an honest read on where Excel holds up, where it stops, and what actually changes when you move to PLM.
Joe Lauder·Founder, Kōbō·Updated Jul 29, 2026The Short Answer
Spreadsheets are the right tool below roughly 20 styles a season with one or two people and a single supplier. At that size, PLM is overhead you don't need and the switch isn't worth doing. Above it, spreadsheets stop failing occasionally and start failing structurally: the same fabric lives in twelve files, nobody's certain which tech pack the factory actually got, and the person who understands the naming convention is on holiday.
That's the whole comparison in two sentences. The rest of this piece is the detail behind it, because the threshold is less about style count than about how many people and suppliers are reading and writing the same data at the same time. If you're new to the category, our guide to what fashion PLM actually is covers the fundamentals before you weigh up the switch.
I'm not neutral here. I run Kōbō, which is a fashion PLM, so treat the closing recommendation with the scepticism it deserves. What I'd ask you to take seriously is the first half: I spent about a decade running Satta on Excel, Dropbox and email, and most of that time it was the correct decision. Software that tells you spreadsheets were always a mistake is selling you something.
What Spreadsheets Genuinely Do Better
Every fashion brand starts in a spreadsheet, and it isn't out of ignorance. Excel and Google Sheets beat PLM on several axes that matter enormously when you're small, and on a couple that never stop mattering.
They cost you nothing extra - You're already paying for Microsoft 365 or Google Workspace. A season plan in Sheets has a marginal cost of zero, which is unbeatable when your development budget is going into fabric minimums.
There's no schema to fight - You need a column for 'washed twice, second wash only on the indigo'? Add it. PLM systems have opinions about how product data should be shaped, and those opinions are usually right at scale and usually annoying at ten styles.
Everyone already knows how - No onboarding, no training session, no adoption problem. Your pattern cutter, your intern and your factory contact can all open a sheet. That's a real advantage and it's why the switch always has a cost.
Ad-hoc maths is faster - Modelling three margin scenarios against a currency swing is quicker in a blank sheet than in any structured system, and it stays quicker after you adopt PLM. This one never goes away.
They're universally portable - A CSV opens anywhere, on any machine, for the next twenty years. No login, no seat, no vendor.
Where Spreadsheets Break
The failure isn't gradual. Spreadsheets work well, then they work badly quite suddenly, and the trigger is almost always the same: a second person, a second supplier, or a second season running in parallel. Here are the four structural failures, in the order most brands hit them.
1. Nothing is linked
This is the fundamental one. In a spreadsheet, a fabric is a piece of text you typed. If your supplier reprices a jersey or discontinues a colour, nothing in your files knows about it. You go find every BOM, every costing sheet and every tech pack that mentions it, and you edit them one at a time. Miss one and the error stays there until a factory quotes off it. In PLM, that fabric is one record, and every style using it updates when you update the record.
2. Two people, two copies
Google Sheets solved simultaneous editing, which helps. It didn't solve the human version: someone downloads a copy to send a supplier, edits it on the way, and now there are two truths. Add email attachments and WhatsApp and the number of live versions of a tech pack in circulation is genuinely unknowable. The file called final_v3_REVISED_use-this-one isn't a joke about disorganised people, it's what happens when the tool has no concept of a current version.
3. Suppliers can't participate
Your factory doesn't have access to your drive, so the workflow becomes: export a PDF, email it, receive comments in the email body, re-type them into the sheet. That re-typing step is where you personally become the integration layer between your team and your supply chain. I did that job for years at Satta, sitting in the middle as human middleware, and it isn't a job, it's a tax. Every question, every price update and every sample comment passes through one person's inbox.
4. The knowledge is in someone's head
Spreadsheets encode a system nobody wrote down. Why is this column yellow? Because yellow means the fabric is confirmed but the trim isn't, and that rule lives with the person who invented it. When they leave, or go on maternity leave, or just get busy, the season slows down while everyone else reverse-engineers the colour code. Structured systems are worse at flexibility and much better at survivability.
The problem was never that we were disorganised. It's that we were maintaining a database by hand, in a format that has no idea it's a database.
Fashion PLM Software vs Spreadsheets, Side by Side
A straight comparison, including the rows where spreadsheets win. If a vendor's comparison table has a tick in every row on their side, it's marketing, not analysis.
| Area | Spreadsheets | PLM | Better |
|---|---|---|---|
| Cost to start | Effectively free, already in your Microsoft or Google subscription | $140-$300 per user per month on Kōbō; more on legacy suites | Spreadsheets |
| Time to first use | Minutes. Everyone already knows how to use a sheet | Days to weeks, depending on the platform | Spreadsheets |
| Flexibility of structure | Unlimited. Any column, any layout, any one-off model | Structured by design. You work the way the system expects | Spreadsheets |
| Ad-hoc maths and scenarios | Fastest tool there is for a quick margin or FX what-if | Built-in costing, but less freeform than a blank sheet | Spreadsheets |
| One source of truth | Whichever file the person opened last | One record per style, one current version | PLM |
| Version history | File names, or nothing | Change history on the record, with who and when | PLM |
| Supplier collaboration | Emailed PDFs and re-typed replies | Supplier logs in and updates the record directly | PLM |
| Linked data | A fabric change means editing every file it appears in | Change the component once, every BOM using it updates | PLM |
| Search across the season | Ctrl+F, one file at a time | Search every style, component and supplier at once | PLM |
| Status visibility | Ask the person who owns the tab | Critical path and sample status on a shared view | PLM |
| Handover when someone leaves | The logic lives in their head | The logic lives in the system | PLM |
| Access control | Whoever has the link | Per-role permissions, suppliers see only their work | PLM |
Read the pattern rather than the score. Spreadsheets win on cost, speed to start and freedom. PLM wins on everything that involves more than one person, more than one supplier, or more than one point in time. Which column matters more is a function of your size, not of which tool is objectively better.
Excel for Fashion Product Development: The Real Limits
People usually assume the Excel problem is presentation, so they fix it with a better template. Nicer tech pack layout, locked cells, a data-validation dropdown for size runs. It helps for a season. It doesn't address any of the four failures above, because those are properties of the file format rather than of your template.
Three specific things Excel can't do for garment development, no matter how good your spreadsheet skills are:
Hold images as data - Fashion development is visual. Fit photos, sketches, print artwork and lab dips are the substance of the conversation, and in a spreadsheet they're floating objects that break when you sort a column.
Track a measurement across sample rounds - A point of measure has a spec, a proto result, a fit result and a PP result, all of which need to sit alongside each other and be comparable. That's four dimensions in a two-dimensional grid, which is why brands end up with a tab per sample round and no way to see drift.
Enforce anything - Nothing stops a supplier returning your costing sheet with a formula overwritten by a typed number. You often won't notice until the landed cost is wrong at PO stage.
None of this means your spreadsheets were bad. It means you were using a general-purpose tool for a specialised job, which is a completely reasonable thing to do until the job gets big enough to justify a specialised tool.
When to Switch From Spreadsheets to PLM
Style count is the usual proxy, and it's a rough one. The more reliable test is how many people read and write the same product data. Here's the checklist I'd use. Three or more of these and the switch pays for itself; one or two and you're probably fine where you are for another season.
The last one is worth flagging separately. Wholesale accounts and compliance schemes increasingly want a defensible audit trail of what was specified and when, and reconstructing that from email is miserable. If you're heading into that territory, the timing decision gets made for you.
What You Give Up Moving to PLM
Any comparison that presents this as pure upside is lying to you. Moving to a structured system has real costs, and they're worth naming before you commit.
Flexibility - A PLM has a data model. Yours will fit it about 90% of the time, and the remaining 10% will involve either changing how you work or living with a workaround. That trade is worth it at scale and irritating at first.
A real adoption cost - Your team is fluent in Excel and will be slower in the new system for a few weeks. Budget for that dip rather than being surprised by it. The brands that struggle are the ones where one person adopts and everyone else quietly keeps their sheet.
A monthly bill - Spreadsheets are effectively free. PLM isn't, and the line item is visible in a way that lost hours never are. That's a genuine argument against switching too early.
Some history stays behind - Most teams import active and recent seasons and leave older archives where they are. You keep the files, but the full back catalogue usually doesn't come across, and that's normal.
The counterweight is that these costs are one-off and front-loaded, while the spreadsheet costs are recurring and grow with your style count. That asymmetry is the actual argument for switching, and it only holds once you're past the threshold.
The Cost Comparison, Honestly
Spreadsheets cost nothing beyond seats you already pay for. PLM has a price. Kōbō is $140-$300 per user per month, billed monthly with no setup fee and no multi-year contract, and supplier seats are free, so you're not paying per factory and fabric mill you invite. Legacy enterprise suites are a different market: typically $50,000 to $250,000+ a year in licensing, plus implementation. If you want the full field, we've compared the main fashion PLM platforms and their pricing in detail.
The honest way to evaluate it is not "software cost versus zero". It's software cost versus the hours your team currently spends maintaining, reconciling and chasing files, plus whatever a repeat sample round or a wrong-spec production run costs you. I'd rather you did that sum with your own numbers than quoted an industry statistic at you, because the industry statistics in this category are mostly vendor marketing. Take your team's hourly cost, estimate the hours honestly for a month, and compare.
For a lot of brands the maths won't clear the bar, and that's a legitimate result. For a brand at 40 styles a season with five people and six suppliers, it usually clears it comfortably, and by then the bigger cost is the mistakes rather than the hours.
How the Move Actually Works
The fear of migration keeps brands in spreadsheets longer than the spreadsheets deserve. On a modern cloud platform it's a one to two week job, and most of that is preparation rather than software.
Tidy before you import - Agree component names, sizes and colour codes first. Importing a mess produces a structured mess, and every hour spent on naming here saves several later.
Import your styles - CSV import from your existing sheets. Your current data isn't wasted, it's the starting point. Bring the active season and the last one; archive the rest as files.
Build the component library - The fabrics and trims you use repeatedly become records once, and every BOM references them from then on. This is the step that removes the twelve-files-to-edit problem.
Invite the team, then the suppliers - Get internal use working for a couple of weeks first, then open supplier access. Bringing factories in on day one while your own team is still learning tends to go badly.
Start new development in the system - Don't backfill history. Run the next season in PLM and let the old seasons stay where they are.
Modern PLM is self-serve. There's no six-month implementation, no consultant, no IT department required. That's genuinely different from how this category worked ten years ago, and it's the main reason the switch is now reasonable at a size where it used to be absurd.
Frequently Asked Questions
When should a fashion brand switch from spreadsheets to PLM?
The practical threshold is around 20 to 30 styles a season, three or more people touching product data, or more than a couple of suppliers. Below that, a well-kept spreadsheet is genuinely the better tool and the switch isn't worth it. Above it, the signal is behavioural rather than numerical: you're spending more time reconciling files than developing product, you've sent a factory the wrong version at least once, and nobody can answer 'where is this style right now?' without asking three people.
Is Excel good enough for fashion product development?
Excel is good enough for a long time, and better than a lot of software vendors admit. It handles specs, costings, and season plans perfectly well for a small team working on a shared drive. Where Excel runs out is linked data and concurrency: nothing connects a fabric to the twelve BOMs that use it, nothing stops two people editing two copies, and nothing records who changed the sleeve length or when. Those are structural limits of the file format, not habits you can fix with a better template.
How much does fashion PLM cost compared to spreadsheets?
Spreadsheets cost roughly nothing beyond the Microsoft 365 or Google Workspace seats you already pay for, so PLM is always the more expensive line item. Kōbō is $140-$300 per user per month with supplier seats included free, billed monthly with no setup fee. Legacy enterprise suites like Centric typically run $50,000 to $250,000+ a year plus implementation. The comparison worth making isn't software cost against zero, it's software cost against the hours your team currently spends maintaining files and the cost of the production mistakes that come out of version confusion.
Can I keep using spreadsheets alongside PLM?
Yes, and most teams should. PLM should hold the record: styles, BOMs, measurements, suppliers, production status. Spreadsheets stay useful for one-off analysis, board maths, buy plans, and any modelling that doesn't need to be the source of truth. A good PLM exports clean data so the sheet you build from it is accurate. The failure mode to avoid is keeping product data in both places at once, because then you're back to two versions of the truth.
How long does it take to move from spreadsheets to PLM?
On a modern cloud platform, one to two weeks for most brands. The work is mostly data preparation: tidy your style list, agree your component naming, then import via CSV. Teams typically start the next season's development in the system and leave finished seasons in the archive rather than backfilling years of history. Legacy enterprise implementations are a different category and run six to eighteen months with consultants.
Disclosure: Kōbō is our product, so we have a commercial interest in this comparison. We've tried to be straight about where spreadsheets are the better choice and what you give up by switching. Competitor pricing was gathered from publicly available sources as of July 2026 and should be verified with each vendor.
Joe's the founder of Kōbō Labs. Before this, he founded Satta, a fashion brand he scaled to sell internationally at Mr Porter, SSENSE, and Beams Japan. A decade of running his own brand - design, suppliers, production, the lot - is what Kōbō is built on.
Related Articles
Outgrown the sheet?
Import your styles, invite your team, keep your suppliers on free seats. Most brands are running in one to two weeks, with no setup fee and no long contract.
Start Free Trial