A new way to deliver images
The WeTransfer wasteland
Every photographer knows this pain: You’ve just delivered images from a client shoot. You have uploaded them to WeTransfer, pinged the client just to make sure they see the delivery.
Then, inevitably:
Two weeks later
– Hi Andreas, the link isn’t working anymore. Could you resend?
Three weeks later
– I can’t find the email with the photos. Can you send them again?
One month later
– My colleague needs access to the images. Could you create a new link?
Each re-submission of the link, or even worse, re-upload of the images takes
Sketching the solution
A lot of my clients compliment my photo-portfolio, now and then I hear, «Can’t we have the same image gallery on our website?»
That in combination with my previous Ai builds I grabbed Figma and wireframed what I actually wanted:
An image bank for each client that looks like my portfolio but is theirs. Advantages:
- Clients get permanent access to their images
- I upload once, they download forever
- Clean, branded experience (not some generic file-sharing site)
- Easy for clients to browse and select specific images
- Controlled access (only specific clients see their projects)
Building the vision
I showed Claude my wireframes and described the workflow I wanted:
«I would like help building a php based image bank function for my website www.nofont.com. The purpose of the plugin is to get a url like www.nofont.com/client-name-image-bank or www.nofont.com/another-client-image-bank where my clients can view and download images that I have taken for them.
It will be hosted on a Digital Ocean droplet running Nginx.»
The full prompt is fairly lengthy so I’ve put it at it’s entierty at the end of the post.
Claude immediately understood the concept and gave me follow-up questions:
- How do you want to organize the images?
- Should clients need passwords or just know the url?
- Do you want usage analytics?
- How should the gallery display work?
Within a an hour or two, we had a working prototype.
The magic of simplicity
The final system is beautifully straightforward:
Admin Side – I log in, see all active image banks, can create new ones, upload images via drag-and-drop, and preview how clients will see their gallery.
Client Side – They get a clean, minimalistic gallery showing their images in a grid. Click any image to view full-size. Download individual photos or grab everything as a zip file.
The url – Something like nofont.studio/imagebank/client-name. Professional, memorable, permanent.
The unexpected delight factor
What I didn’t anticipate was how much clients would love this experience. Instead of hunting through email attachments or rushing to download before links expire, they can casually browse their images whenever need or inspiration strikes.
I’ve had clients forward the galleries to press and media, marketing teams share the url internally instead of forwarding email attachments.
One client told me: «This is how image delivery should work. Why doesn’t everyone do this?»
Good question.
The professional upgrade
This experience is not life changing o technically revolutionary, but it makes a huge difference in how clients perceive my service. Instead of generic WeTransfer pages with random ads, they see a clean, professional gallery that feels like an extension of my brand.
The permanence factor is psychologically powerful too. Clients feel more confident about their image investment when they know the photos aren’t going to disappear in
Technical simplicity, professional results
From a building perspective, this was surprisingly straightforward. The image bank is basically:
- A simple login system for me
- File upload and organization
- A gallery template that displays images nicely
- Basic access control (each project gets its own url, each vclient a login)
No complex databases, no cloud storage apis, no subscription services. Just files in folders with a clean web interface on top.
The whole system runs on my existing website hosting, costing me nothing extra.
The ripple effects
Building this image bank had unexpected benefits beyond solving the WeTransfer problem:
Portfolio organization – I now have a clean record of every project with easy access to all images.
Client retention – when clients need images months later, they come back to my site and quite often browse other parts of it.
Professional positioning – the polished delivery experience reinforces my professional brand throughout the entire client relationship.
Time savings – no more re-uploading, re-sending, or explaining why links don’t work anymore.
The WordPress plugin bonus
A client loved the system so much they asked if I could implement something similar for their WordPress site. Within
That client project paid for several months of my Claude subscription while giving me a reusable tool I could offer to other clients.
The Swedish satisfaction
There’s something deeply satisfying about solving a problem once and never dealing with it again. Very Swedish approach: identify inefficiency, build proper solution, move on to more interesting challenges.
No more WeTransfer anxiety. No more apologetic emails about expired links. No more re-uploads.
Just clean, professional image delivery that works the same way every time.
Next up: How I made accounting bearable by teaching ai to read my invoices and bank statements.
Original prompt:
I would like help building a php based image bank function for my website www.nofont.com. The purpose of the plugin is to get a url like www.nofont.com/client-name-image-bank or www.nofont.com/another-client-image-bank where my clients can view and download images that I have taken for them.
It will be hosted on a Digital Ocean droplet running Nginx.
I have atteched wireframes for reference.
Please use css classes and structure from the «Nofont Framework». The css file is in the Project Knowledge.
Functionality:
Users
“Image bank - login.jpg”
Since the image bank will be manually set up by me the user roles can be listed in a separate .json file that can be edited manually via code editor. Two user roles shall be available:
* Administrator: can access the admin interface and crud image banks, images and texts.
* Client: can access the public view specified for at specific image bank that is defined in the .json-file along with username and password.
So no image bank is accessible publicly without logging in.
Administrator functionality
Accessing the image bank admin interface
“Image bank - dashboard.jpg”
Only the admin role shall be able log in and view the image bank dashboard. On the dashboard is a list of existing Image banks + a “Create image bank”-button.
Adding a new image bank
“Image bank - detail view - create or edit image bank.jpg”
Clicking the “Create image bank”-button, or the “Edit”-button for an existing image bank, leads to the image bank details view where the user can name, define an url and upload images to the image bank. If there is already images uploaded to the selected image bank the administrator can see a list of all images here.
Uploading images
Uploading new images is done in via the browsers native upload functionality. All images uploaded to an image bank shall be stored in a folder named after url-slug the image bank has. The only thing is that the user must be able to type in a “Description” text for each uploaded image.
Approved image format: .jpg and .png
Editing images
“Image bank - edit image.jpg”
The administrator shall be able to edit each individual image in the lists by clicking the “Edit”-button. The image data is edited via a modal
Image scaling functionality
When an image is uploaded it shall be saved in three versions:
1. Thumbnail - 100x100 px - used in lists
2. Preview - 500x500 (whichever is the longest side of he image) - used in the Masonry-style grid view for each image bank.
3. Original - no scaling - used for downloads
Client functionality
“Image bank - Masonry style public view.jpg”
“Image bank - Full size preview image.jpg”
Public viewing of image banks
When a visitor access one of the image banks the page shall list selected images in a Masonry grid style format. On hover the image shall be covered with an overlay that displays: Description, name and buttons for full-screen preview and download. The download button shall download the original high resolution version of the image. See attached wireframe ”5. Image bank - Masonry style public view”.
Proposed file structure
Image-bank/
│
│– index.php
│
│– images
│ │– image-bank-url
│ │– image-bank-url
│ └─ image-bank-url
│
│– public-view.php
│– upload.php
└─ users.json
Questions?
* Do we need a database setup for this? It will be a very low frequently used service, so would creating .json files for storing image bank (id, name, url and image-ids) and image data (id, description and filename) be sufficient instead of a db?