FROM AI IDEA TO BUSINESS SOFTWARE
Build business software with AI.
You know the business. Together, we turn ideas into working systems.
Practical input: Sven Miller, Miller Development. Based on his description of our customer collaboration.
Start with the business problem and choose a small first outcome. Use AI to explore workflows and make ideas concrete, ideally with feedback from a development team along the way. Before live use, review the solution and adapt security, architecture, performance and integrations as needed. Customers can keep contributing when responsibilities and ways of working are clear.
AI lowers the barrier — the need determines what to build
Many needs involve familiar digitalisation: bringing information together, reducing repeated work and supporting a workflow. AI can make it easier to see the opportunity and create a first proposal. The finished system does not need to use AI at runtime simply because AI helped build it. Start with what should improve in the business rather than the tool to use.
Start from where you are
Customers start in different places. One needs help describing a need and understanding what is possible. Another has already made substantial progress with Lovable, Claude Code, Codex or a similar tool. Collaboration depends on the customer’s skills, available time and intended use. We prefer to get involved early, but a clear prototype can also make a later handover much easier.
| Starting point | Customer contribution | Miller Development contribution |
|---|---|---|
| A problem or idea | Show the work, consequences and desired result. | Help understand the need, prioritise and choose a first step. |
| An early AI prototype | Try workflows and show what works or does not. | Give feedback on scope, technology and constraints before handover. |
| An advanced AI build | Explain behaviour, decisions and what has been tested. | Review the solution and decide what to keep, improve or rebuild. |
1. Prioritise business value and choose a first delivery
We prefer to start with a prioritisation workshop and an MVP workshop. These help the business agree on the most important problem and what the first version needs. The format adapts to the people and their experience; it is not a compulsory sequence of meetings for every customer.
- Who has the problem, and how does it show up today?
- Which change would create value, and how will we review it?
- What is the smallest complete workflow to start with?
- Which features can wait?
When starting is easy, the most motivated person or department can move quickly. Our recommendation is to make priorities visible at the same time: the easiest initiative to start is not always the one creating the most value for the company.
Start with a small delivery that creates real value. The rest can wait.
2. Let the customer explore, with feedback along the way
Customers can use AI to describe what they want to achieve and try how it might work. A prototype makes the conversation concrete: this flow is right, this is missing and this may not be needed at all. In our preferred collaboration, the proposal goes back and forth between customer and team before handover. This helps uncover unclear needs and technical choices before more work is invested.
Feedback should help the customer move forward. Ask what the next test should establish and keep the first workflow small. Use appropriate test data and agree before connecting real company data or external systems.
3. Make handover a shared next step
Demonstrate an important workflow from start to finish. Summarise user needs, what has actually been tested, uncertainties and exclusions. Give the team controlled access to the project, code, database and required settings. Screenshots or a long AI chat rarely provide the whole handover.
A handover does not mean every question is settled or that the entire prototype should become production code. Agree on what the team should assess first and the evidence needed for the next decision.
4. Establish technical responsibility before live use
Our initial review asks three questions: is it secure, can it be developed further, and who owns and operates it? We then plan the work required for the intended use. This may include permissions, the data model, architecture, performance, integrations and how updates are deployed.
Some working components may be reusable. Others need improvement or replacement. This is an assessment of the specific solution. Prototyping may still have created substantial value through clearer needs, tested workflows and shared understanding.
A concrete idea also needs security, technical ownership and an operating plan.
5. Let customers keep contributing after handover
When customers want to keep working on code with AI, we usually arrange a separate development track: a branch. They can explore changes there while the team is responsible for the shared technical solution. Changes need review, testing and integration with the shared code before becoming part of a release.
A separate branch does not itself protect data, permissions or connected services. The team must also agree on test environments, permitted data and who can publish. For the business, the important thing is a clear way to keep contributing without accidentally changing the system others use.
6. Review the value and choose the next step
Have intended users try the bounded delivery and review outcomes against the need. Then choose whether to improve the workflow, add the next part or stop developing. Once systems are in place, collaboration may move into maintenance. New needs also often emerge as the business starts using the solution.
Clear ownership of business outcomes, technology and operation matters more than who built each part. Keep asking: can the user get value without this feature? If so, it may be able to wait.
PRACTICAL TEMPLATE
Five lines before the first conversation
Use the headings as a starting point for your conversation. Leave secrets and customer records out of the document.
We want to make this easier in the business: … We have already tried or built: … The first user and most important workflow: … What remains unclear: … The next step we want help with: …Download template (.txt) ↓
Common questions
Do we need to have built something with AI before contacting you?
No. We prefer to get involved when you have a business problem or an idea. If you already have a prototype, we use it to understand the need and plan the next step.
Does the customer need to know how to code?
No. Customers contribute business knowledge, examples and tests. Those who want to and can work on code can also keep exploring with AI in an agreed development track.
Do you always take over and rebuild everything?
No. We assess what can be used, improved or rebuilt for the intended use. A working demo does not establish production readiness, but AI-generated code does not automatically need replacing.
Does AI development mean the finished system must contain AI?
No. AI can be a tool for exploring and building ordinary software. If the system also uses AI at runtime, that functionality needs separate assessment and testing.
Sources and method
The review structure, examples and templates are Miller Development’s practical recommendations, informed by Sven Miller’s description of our approach. The references explain related principles; they do not validate these templates or certify a solution. Platform features and terms can change. This guide does not replace a review of your specific system.
Lovable states that its security scans cannot guarantee complete security or replace a thorough review.
MILLER DEVELOPMENT
Want help taking the next step?
We help prioritise business value, review AI-built solutions and develop secure, stable systems integrated into your business. The next step may be a small test, a technical review or a bounded first delivery.
Talk to us ↗