Skip to main content

Blog

Spreadsheet, fixed app, or custom schema: what each costs you at 100, 500 and 2,000 items.

Published 16 October 2026

There are three ways to keep a list of what you own. You can build a spreadsheet, one column at a time, and put whatever you like in it. You can use an app that hands you a form the moment you sign up. Or you can describe your own fields, give each one a type, and let the app hold you to them.

The first is free and familiar. The second is quick if your hobby is already covered. The third costs you a few minutes before you add a single item. Each of them looks cheap at the start. The costs that matter arrive later, and at a different collection size in each one.

Here is what each of them costs at 100 items, at 500 and at 2,000.

Three shapes for the same shelf

A spreadsheet is a grid with no opinions. You type the header row, and the sheet checks none of it. Two spellings of the same publisher sit in the same column, and the condition column holds “NM” in one row, “Near Mint” in the next and “near mint” in a third. You get speed and no rules.

A fixed app is a catalogue with a form on the front. Discogs will not take a new release without a main artist, a title, a label, a catalogue number, a format, a genre and the full tracklist, because it is a database of pressings and those fields are what a pressing is. Card apps arrive at the same place from the other end: Collectr matches a scanned card against a catalogue of 200,000 products spread over more than twenty games, and TCGplayer lists a single by finding the product in its catalogue first. You get pricing and set data out of that, and you pay for it with someone else's field list.

A custom schema is the third option. You choose the fields, and each one has a type: text, a longer note, number, dropdown, date, currency, rating, year, a range. The type is set when you create the field and cannot change afterwards, so the thinking happens once, at design time, and then adding an item is a form with your fields in it.

At 100 items, any of the three works

A spreadsheet does not break at a hundred rows. Each approach holds a hundred items without strain, and the difference is what goes wrong first.

With a spreadsheet, it is the text. A hundred rows is enough for the condition column to drift, and once it drifts you cannot count it. How many are near mint? The sheet cannot say, because near mint shows up four ways and the sheet treats those as four different words. What you enter by hand, you later clean by hand.

With a fixed app, it is the catalogue. If your thing is in it, the catalogue does the matching and the pricing for you, which is the best deal in collecting. If your thing is not, you are fighting the form. A die-cast collector sitting in front of a record database finds no field for the casting, none for the tampo, and no way to add either.

With a schema, it is the design. Ten minutes deciding what a record is for you, and then the fields agree with each other for as long as the collection exists. Our first-collection guide walks through the whole thing, and that ten minutes is the only upfront cost the approach has.

At 500 items, the sheet starts asking for maintenance

At 500 items the spreadsheet has stopped being a list and started being a system, which is not the job you gave it. Adding an item still takes the same effort. The work around the adding gets worse.

Sort the range and rows move under the formulas. Checking whether you already own something means scrolling the list, because a duplicate is a thing you have to see. Trying to show only the items with no photograph yet gives you no control to reach for, because a photograph in a spreadsheet is a link in a cell and the sheet has no idea it is a picture.

That last point is the one that generalises. A filter is what replaces scrolling, and a filter needs a field to work on. In collectd, three field types become filters: a dropdown with options, a tick box, and a rating. The count above the grid updates as you filter, so “seventeen of twenty-four” is a number you can read rather than a total you have to trust. The fields you chose in the first ten minutes decide what you can ask the collection a year later.

A fixed app has the opposite problem. The form is fast, and fast is what you want when you are adding item four hundred. But a field the catalogue does not have is a field you cannot sort or count, so the shop, the seller, the price you paid and the reason you bought it end up in one free-text box, where you cannot sort or count any of them.

At 2,000 items, size is not what breaks

The obvious worry at 2,000 items is that the spreadsheet runs out of room. It does not. Two thousand rows across twenty columns is 40,000 cells, and Google Sheets holds up to 20 million cells in a single spreadsheet as of September 2026, up from 10 million. Excel gives one worksheet 1,048,576 rows and 16,384 columns. Both are far larger than any private collection you will meet.

At this size the problem is consistency rather than capacity, and it shows up in single rows.

You will not reread 2,000 rows. A mistake in row 74 is invisible until you are standing in front of a buyer, and by then you are arguing from memory. A row you forgot to mark as sold leaves the sheet wrong in a way you cannot see. Two spellings of the same maker split one run into two, and the sheet cannot tell you, because it has no opinion about what a maker is.

Then there is proof. At claim time, at sale, or when someone asks what the thing is worth, the record is doing real work: condition, what you paid, when, from whom, and a photograph from the day it arrived. That is a set of typed fields. In a spreadsheet it is 2,000 rows of your own shorthand, and shorthand is only as good as your memory of writing it. There is a reason we wrote a whole post about photographing an item like evidence.

Sharing has its own cost. Hand over the spreadsheet and you hand over the cost column, the notes, the lot. A public gallery shows what you choose to show.

Where the spreadsheet wins

There are cases where the spreadsheet is the better tool, and they are worth naming.

Under about 300 items, with six columns or fewer, no photographs, one person doing the collecting, and no plan to sell or claim, a spreadsheet is the right answer. It is free, it opens at once, and you already know how it works. A schema would be a solution to a problem you do not have yet.

If you want arithmetic, the spreadsheet wins outright. Pivot tables, running sums, spend by year, and a formula that does something particular to your hobby are things no collection app will do as well as a grid you control. Schema apps count, filter and sort. They are not calculators.

And if your hobby has a real catalogue and you want its prices, use the fixed app. It will be faster than anything you build and the data will be better than anything you maintain by hand. The trade is that the fields are theirs.

What the schema costs

The third option is ours, so the trade should be plain.

A schema charges you ten minutes before the first item. You decide what a record holds, name the fields, and give each one a type. It is work you can skip in a spreadsheet, and work that someone else has already done in a fixed app.

You spend ten minutes, and what you get is a record whose fields agree with each other at a size where the spreadsheet cannot, and one that anyone can read without asking you what a column means. The types do the checking as you add items, so the tidying you would do by hand with a sheet does not come back.

The cost lands at the start, in one go, and it does not grow with the collection. That is the trade.

Choosing in a minute

Four questions, in order.

Is there a catalogue that already covers your hobby, and do you want its prices? If yes, use the fixed app and accept the form. It is quicker than building anything.

Will you pass 300 items in the next year, or want photographs in the record? If no, keep the spreadsheet. It is not the lesser answer at that size, it is the cheaper one.

Will anyone else ever read this record, whether a buyer, an insurer, or the person who ends up with the collection after you? If yes, the record needs types, because it has to be readable by someone who is not you.

And if the answer is a schema, the design work takes ten minutes and then you are adding items. Start with the first-collection guide, and keep the fields guide open while you choose the types.