Define the change for one user
Begin with a user, a recurring situation and a measurable improvement. Replace broad statements such as businesses need better automation with a concrete claim: a catalogue team should be able to publish approved product updates in hours instead of days.
This definition becomes the decision filter for features. If a feature does not help the target user reach the promised outcome or help the team learn whether the promise is valuable, it probably does not belong in the first release.
Map assumptions before features
Every product idea contains assumptions about demand, behaviour, technology, data and economics. Rank them by how damaging they would be if false. A landing page, interview, manual service or interactive prototype can test many assumptions before production code is necessary.
Validation is not a collection of compliments. Strong evidence includes a pre-order, a signed pilot, access to real data, repeated use or a customer changing an existing process to adopt the solution.
Design the smallest complete product
A minimum viable product should be small, but it must complete the core journey. Authentication, payments, error handling and support may be less exciting than the signature feature, yet they often determine whether the product works in real life.
Write acceptance criteria for the main journey and define what will be measured. This creates a shared contract between strategy, design and engineering and reduces expensive interpretation during the build.
Build for learning, then operate
Use short releases and observe real behaviour. Instrument the product from the start so the team can see activation, completion, failure and retention. A launch is the beginning of product development, not its final ceremony.
Wishmakers works from concept to operation because the decisions made after launch are inseparable from the original design. Real products require maintenance, support, infrastructure and a clear rhythm for improvement.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering Contact Wishmakers
Frequently asked questions
Do I need a technical specification before contacting a product company?
No. A clear description of the user, problem, constraints and desired outcome is more useful at the beginning.
How long should an MVP take?
It depends on risk and scope. A focused product can often be tested in weeks, while regulated or integration-heavy systems require more preparation.
Should I protect the idea before discussing it?
Confidentiality can be appropriate, but execution, insight and access to users usually matter more than secrecy alone.
When SaaS is the stronger choice
Choose SaaS when the process is common, the product meets most requirements and speed matters more than control. Accounting, basic CRM and collaboration are typical categories where established services can be difficult to justify rebuilding.
Include implementation, licences, add-ons and process changes in the comparison. A low monthly headline can become expensive when every user, market or integration adds another fee.
When custom software earns the investment
Custom development becomes compelling when the workflow is distinctive, existing tools create repeated manual work or the system directly shapes customer value. It can unify fragmented operations, encode proprietary knowledge or support a business model that generic software cannot serve.
Ownership creates freedom, but also responsibility. The business needs a plan for security, hosting, maintenance and continuous improvement. Custom does not mean building every component from zero. Mature services and open technologies can reduce time and risk.
A five-part decision framework
Evaluate strategic differentiation, process fit, integration complexity, total cost over three to five years and the cost of delay. Score each option with the people who operate the process, not only those who purchase the tool.
Pay attention to reversibility. Exportable data, documented APIs and modular architecture preserve options. Vendor lock-in and undocumented custom code can both become constraints.
The hybrid option
Many strong systems combine SaaS infrastructure with a custom operational layer. The business keeps commodity functions where they belong and builds only the workflows that create a meaningful advantage.
Wishmakers approaches software decisions from the product outcome backward. The goal is not to maximise custom development. It is to create the simplest dependable system that fits the business and can evolve with it.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering Automation
Frequently asked questions
Is custom software always more expensive?
It usually costs more initially, but can be economical when licence growth, manual work or poor fit make SaaS expensive over time.
Can a SaaS stack be automated?
Yes. APIs and automation platforms can connect services, although reliability and vendor limits must be assessed.
Who owns custom software?
Ownership depends on the contract. Intellectual property, source code, infrastructure and third-party components should be stated clearly.
Look for product judgement
Ask candidates to challenge the brief. A strong partner should identify the main user outcome, the riskiest assumptions and the smallest useful release. A team that agrees with every requested feature may be optimising for project size rather than product success.
Request examples of decisions, not just screenshots. What was removed? Which assumption changed? How did user evidence alter the roadmap? These answers reveal how a team thinks when information is incomplete.
Examine production capability
A polished prototype is not evidence of reliable engineering. Discuss authentication, data protection, testing, deployment, observability, backups and incident response. If AI is involved, add evaluation, fallback behaviour and cost monitoring.
Clarify who owns architecture and technical documentation. The system should remain understandable beyond the individuals who first built it.
Evaluate the working model
Good collaboration has explicit decision rights, a visible backlog and frequent demonstrations of working software. Ask how scope changes are handled and how risks are communicated. Silence until a large milestone is rarely a sign of control.
Commercial models should support learning. A staged engagement with clear outcomes can be safer than a large fixed commitment based on uncertain requirements.
Check alignment after launch
Products need operation, measurement and iteration. Establish whether the partner can support the launch and how knowledge will transfer to an internal team. Define service levels only where they match genuine business risk.
Wishmakers builds and operates products of its own. That operating exposure informs decisions about reliability, payments, users and the less visible work required to keep a digital product useful.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Frequently asked questions
What should I prepare for a first meeting?
Bring the user problem, business objective, constraints, existing systems and any evidence from customers. A feature-complete brief is not required.
Should I choose a specialist or a generalist?
Choose the team whose relevant experience reduces your main risk. Domain insight may matter more than a specific framework.
How can I compare proposals?
Compare assumptions, exclusions, team composition, delivery method, ownership, post-launch support and total expected cost, not just the headline price.
A demonstration follows the happy path
Prototypes are designed to make the central idea visible. They can rely on clean sample data, known user behaviour and manual intervention. Production systems face incomplete records, duplicate actions, interrupted payments, forgotten passwords and unexpected demand.
List the failure modes of the core journey before scaling. Decide what the user sees, what the system records and how the team recovers. Graceful failure is part of the product experience.
Quality must become measurable
Production teams need automated tests, release checks and monitoring. For AI systems, conventional tests are not enough because output quality may vary. Representative evaluations and thresholds must be defined for the tasks that matter.
Measure latency and cost as part of quality. An impressive result that takes too long or costs more than the user creates is not production-ready.
Security and operations become product features
Access control, encryption, backups, logs and dependency management affect trust. The appropriate level depends on the data and the consequence of failure, but these decisions cannot be postponed indefinitely.
Assign ownership for alerts, support and incidents. A dashboard without someone responsible for acting on it creates visibility, not resilience.
Use a production-readiness gate
Before launch, review users and permissions, data flows, integrations, error states, performance, monitoring, support, legal requirements and rollback procedures. Run the complete journey with realistic data.
Wishmakers treats operation as part of product design. Moving from a promising prototype to a dependable system requires coordinated product, engineering and business decisions.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering AI Systems
Frequently asked questions
Can a no-code prototype go into production?
Sometimes, if the platform meets the product’s security, scale, integration and ownership needs. The decision should be based on risk, not stigma.
What is production readiness?
It is the evidence that a system can serve intended users reliably, securely and supportably under realistic conditions.
Should every MVP be scalable?
It should support the next credible stage without unnecessary complexity. Designing for hypothetical global scale can delay learning.
User and problem
Ask: Who experiences the problem most often? What are they trying to accomplish? What triggers the situation? How do they solve it today? What does delay or failure cost them?
Observe behaviour where possible. A reported frustration is weaker evidence than a repeated workaround, budget line or missed opportunity.
Demand and differentiation
Ask: Who pays? What commitment have users made? Which alternatives compete for the same budget? Why would the product win? What advantage is difficult to copy?
Do not define the competitor list too narrowly. A spreadsheet, assistant or decision to do nothing may be the strongest alternative.
Feasibility and risk
Ask: Which data and integrations are required? What must be accurate? What are the security or legal consequences? Which assumption could make the product impossible? What is the smallest test?
For AI products, define examples of good and unacceptable output before choosing a model. Evaluation starts with the job, not the technology.
Economics and operation
Ask: What creates revenue or measurable value? What will each use cost? How will users be acquired? Who supports the product? What evidence will unlock the next investment?
Write the answers in one short discovery brief and identify what remains unknown. Wishmakers uses discovery to connect product ambition with an executable, operable system.
Build what comes next
Turn the idea into a working system.
Wishmakers designs, builds and operates AI-native products, software systems and digital ventures across Europe, Morocco and Brazil.
Product Engineering Contact Wishmakers
Frequently asked questions
How long should product discovery take?
It should be proportionate to the investment and risk. Focused discovery may take days or weeks, while complex regulated products need more evidence.
Does discovery end when development starts?
No. Discovery and delivery continue together as real product evidence changes the roadmap.
What is the output of discovery?
A clear problem, target user, tested assumptions, scope recommendation, risk map and next decision.