Discovery
Users, workflow, constraints, risks, and the smallest release worth funding.
Custom software · Portugal and Europe
Software built around the work your off-the-shelf tools cannot quite handle.
I design and build web products, internal tools, integrations, and data systems for teams with a specific operational need. The first job is to prove that custom software is justified; the second is to keep ownership and operating cost clear.
Direct answer
When is custom software worth building?
Custom software is worth building when the workflow differentiates the business, existing products create costly workarounds, or owned logic and data access matter. It is usually a poor choice for a standard problem already solved well by maintained software. The decision should compare lifetime cost, control, integration risk, change frequency, and the consequence of depending on a vendor.
When this helps
The strongest projects begin with a recurring operational constraint, not a feature list.
- A core workflow is split across spreadsheets, inboxes, and disconnected SaaS tools.
- Customers or staff need a focused interface that existing software cannot provide.
- The company needs owned logic, permissions, or integrations around sensitive operations.
- A prototype has proved demand but cannot support the next stage safely.
- A legacy application needs a deliberate recovery or replacement path.
What the work covers
From product decision to an operable release.
The deliverable includes the decisions and operating path around the code, not just a repository.
Product and architecture
Interface, data model, integrations, permissions, and technical trade-offs.
Implementation
Full-stack application, tests, deployment, analytics, and release support.
Handover
Documentation, source ownership, operational access, and a clear maintenance plan.
Compare the options
Build only when ownership creates more value than maintenance costs.
| Option | Best when | Trade-off |
|---|---|---|
| Existing SaaS | The process is standard and configuration covers most needs. | Vendor limits and recurring cost. |
| Low-code | The workflow is internal, bounded, and changes frequently. | Complexity can outgrow the visual layer. |
| Custom software | Owned logic, integration, experience, or scale creates advantage. | Requires product ownership and maintenance. |
| Hybrid | A standard core can be extended through APIs and a custom interface. | Integration boundaries must be monitored. |
How the work runs
Decide, reduce, build, and transfer.
Understand the work
Observe users, data, constraints, and the cost of the current workaround.
Choose the boundary
Separate what should be bought, configured, integrated, or built.
Ship the smallest complete path
Deliver one end-to-end workflow with tests and real users.
Make it operable
Document ownership, monitoring, releases, support, and the next product decision.
Relevant work
Built across education, AI, publishing, and on-chain products.
The work archive includes the 42 Network student intranet, 42 Lisboa launch systems, Agentic Brief, smart-contract launches, and Bitcoin inscription infrastructure.
FAQ
Questions before commissioning custom software.
Will we own the source code?
The contract should state ownership, licences, third-party services, credentials, and handover. I make those boundaries explicit before implementation.
Can you work with our existing software?
Yes. A hybrid build around reliable APIs is often better than replacing everything.
How do you estimate a custom build?
After a short discovery, I estimate a defined release with assumptions, exclusions, dependencies, and risk. Large unknowns should become a paid discovery rather than false precision.
What happens after launch?
The proposal defines warranty, monitoring, support, maintenance, and handover. Continuing work is optional and should have a clear operating scope.
Can you rescue an existing application?
Yes, after a technical audit. The result may be stabilisation, staged replacement, or a smaller intervention rather than a rewrite.
Start with the constraint
Describe the workflow your current tools cannot support cleanly.
I will help separate configuration, integration, and custom development before proposing a build.
Discuss the software