Comparing self-hosted photo apps: a worksheet
A long feature list is a difficult place to start when choosing a photo app. Start with the things you need to do: bring in a collection, find a picture, use the library on your devices and recover when something goes wrong. Then give each candidate the same small test. The useful result is a record of what worked for you, what needed extra effort and what remains unanswered.
Use harmless test files throughout. Keep your main collection where it is while you evaluate. There is no need to move personal material just to discover whether a navigation layout or import workflow suits you.
Write down the job first
List your essential devices, preferred server setup and everyday tasks. Separate requirements from nice extras. For example, opening the library on your usual computer might be essential; a particular sorting option might be optional. Write down who will install updates and who will handle a failed import. If that person is you, include the time you can realistically spend.
Use the self-hosted photo library guide to frame those responsibilities. Choose your requirements before trying the apps so a polished demonstration does not quietly change the question you set out to answer.
Check the setup you would actually use
For each candidate, find its current installation instructions and supported platform list. Record the version and date beside your notes. Ask which parts you would run, where you would run them and what equipment is required. Note any separate service, subscription or account involved in the proposed setup.
Try the documented setup with test data, if you have suitable equipment and permission. Record the steps that needed explanation. Treat an unanswered compatibility question as “not verified”, rather than assuming another device in the same family will work.
Give imports the same test
Prepare a small collection of synthetic images with known filenames and dates. Include harmless examples of the formats and organisational patterns that matter to you. Write down the starting file count and the expected result. Use the same collection for every candidate and follow each app's documented import route.
Inspect the result, including any warnings. Can you find the files you expected? What happened to the dates and organisation? If something differs, record the difference and the documented remedy. Do not turn one successful sample into a promise about an entire collection.
Repeat ordinary browsing tasks
Choose several tasks before testing: open a recent image, find an older one, change its organisation and view it on a required device. Note the steps, any confusing wording and any unavailable function. Keep the conditions reasonably consistent, including the test collection and the equipment used.
If you record timings, describe the conditions beside them. Your worksheet is a record of a particular trial, not a general speed ranking. A feature you did not test stays “not verified”, even when a product page mentions it.
Test leaving and recovering
Find the documented export process. With the test collection, check what you can take out and whether the exported files open in the destination you intend to use. List anything that needs a separate export or cannot yet be confirmed.
Next, write a recovery scenario: assume the test installation is unavailable. What saved files, instructions and access would you need to rebuild it? Rehearse the documented process in a separate test setup where practical. The recovery-planning guide gives you questions to put beside that exercise. Keep an untested recovery plan clearly marked as untested.
Count the ongoing work
Record the equipment, storage, subscriptions and maintenance tasks for your proposed setup. Use current quoted costs where available, and leave unknown costs blank with a question to resolve. Ask how updates are announced, where instructions live and what help is actually offered. Distinguish an advertised support option from a response time that has been explicitly committed.
Complete the same worksheet for each candidate
Use one row per requirement, with these columns: requirement; documentation and date; test performed; observed result; unresolved question; ongoing effort. Mark results “observed”, “documented only” or “not verified”. That makes the comparison readable without giving an untested feature a pass.
Choose against your original essentials. If a must-have remains uncertain, ask for evidence or run another harmless test before moving your collection. Keep the worksheet: it can explain your decision now and show what needs checking again after a significant update.