How Should a Freelance Developer in Spain Present SaaS, Apps, and Open-Source Work?
A freelance developer in Spain should present SaaS products, mobile apps, and open-source work on one page, grouped by commercial relevance and backed by a direct link, a plain-language description, and one verifiable result for each project.
A prospect reviewing a proposal does not know which repository, store listing, or landing page matters most. Your job is to remove that research task. The page should work as a compact evidence pack: useful in an emailed proposal, a LinkedIn message, or a call follow-up, while every original source remains one click away.
What should appear first for a Spanish freelance client?
The first screen should state what you build, who you build it for, and show the two or three projects closest to the client’s brief.
Lead with relevance rather than chronology. A working B2B dashboard belongs above a clever weekend library when the prospect needs an internal tool, even if the library is newer. Give each entry a name, a short description, its status, and the destination where the prospect can verify it.
Keep the bio concrete: role, speciality, and location only when location helps the engagement. Avoid turning the page into a duplicate CV; the CV records employment, while this page proves what you can make.
- One sentence defining your speciality and typical customer.
- Two or three relevant projects before the rest of the catalogue.
- A live product, store, demo, or repository link for every claim.
What is the fast way to assemble it with IndieShow?
The fast route is to claim an IndieShow handle, add your profile, and enter each SaaS, app, or repository as a project in the dashboard.
IndieShow provides a personal URL at indie-show.com/yourname and a live preview while you edit. You can upload a profile photo and project logos, choose a page colour, add social links, and reorder the work so the most useful proof appears first.
Use the project status fields honestly. Put products a client can open under Shipped or Built, active experiments under Building or Working on, and retired work under Archived. The price controls publication of the public page; it does not change how you structure the evidence.
Claim your IndieShow pageStart by claiming a handle; after that, the dashboard shows the $15 one-year pass and $30 lifetime option See the editor and publishing options.
How should SaaS, mobile apps, and open source differ on the same page?
Each format should use a different proof link but the same compact description pattern, so the page stays consistent without hiding what makes each project credible.
For SaaS, link to the live product and explain the workflow you built. For a mobile app, link to the relevant store listing and name the platform. For open source, link to the repository or documentation and say what the package solves. Only add a metric when you can substantiate it from a source you control.
Do not write three mini case studies on the overview page. The portfolio is the map; product pages, stores, and repositories carry the depth. A prospect should understand the range in one scan and choose where to investigate.
- SaaS: product link plus the business workflow it supports.
- App: store link plus platform and user problem.
- Open source: repository link plus the developer problem it removes.
What should you leave out of a client-facing portfolio?
Leave out unverifiable numbers, internal client material, vague skill lists, and links that open dead or access-restricted projects.
Confidential work can still appear as an anonymised capability statement, but never imply that a private screenshot is a public case study. If a repository is private, describe the outcome and point to another public example of the same craft instead of offering a broken link.
Check the page before every proposal: open every destination in a signed-out browser, confirm the top projects match the brief, and archive anything that no longer represents the service you are selling.
For the broader structure and the one-page trade-off, read: the indie hacker portfolio guide · link in bio vs. personal website
When is the freelance portfolio ready to send?
It is ready when a prospect can identify your speciality, verify relevant work, and reach the next step without asking you to explain where everything is.
Send one stable URL in the proposal and keep detailed estimates, contracts, and client-specific documents outside it. That separation lets the portfolio remain public and reusable while the commercial conversation stays private.
IndieShow fits this handoff because one handle can stay constant while you reorder, add, or archive projects from the dashboard. The result is a maintained proof page, not another document that becomes stale after one pitch.
Frequently asked questions
What should appear first for a Spanish freelance client?
The first screen should state what you build, who you build it for, and show the two or three projects closest to the client’s brief.
How should SaaS, mobile apps, and open source differ on the same page?
Each format should use a different proof link but the same compact description pattern, so the page stays consistent without hiding what makes each project credible.
What should you leave out of a client-facing portfolio?
Leave out unverifiable numbers, internal client material, vague skill lists, and links that open dead or access-restricted projects.
When is the freelance portfolio ready to send?
It is ready when a prospect can identify your speciality, verify relevant work, and reach the next step without asking you to explain where everything is.