Custom Software and MVP Development: Build a Useful First Version

Custom software is worth building when it solves a clear problem that existing tools cannot handle well. The first release should help real users complete that task. An MVP, or minimum viable product, is a small working version used to test an idea before investing in more features.

A prototype can look finished while basic decisions remain unresolved. Who may approve a request? What happens when a payment fails? Who fixes an error after launch? Answer these questions early, while changes are easier and cheaper.

This guide covers custom websites, mobile apps, internal tools and connections between business systems. A customer relationship management system, or CRM, is one example. The project examples are illustrative, not Lucid Growth Media client results. The aim is software your team can use, check and maintain.

Begin with the work, not a list of screens

Describe the problem as a task someone needs to complete. Who is trying to do what? What happens today? Where does the process become slow, confusing, or unreliable? What would a better outcome look like from that person’s perspective?

For an illustrative booking business, the problem may not be the absence of an app. It may be that staff cannot see current availability, customers do not receive confirmation, and rescheduling requires repeated phone calls. Those problems suggest a connected workflow. They do not automatically justify a native mobile application, loyalty scheme, or recommendation engine.

With permission, watch how people do the task today. Review forms, spreadsheets and messages. Include missing information, duplicate records, cancellations, failed payments and out-of-hours requests. These cases help define the work more accurately than a screen list.

Write a short problem statement that includes the user, task, current obstacle, and desired improvement. Then identify the business owner who can make decisions about that process. A development team can implement rules, but it cannot resolve every disagreement about how the business should operate.

Begin with a shared description of the work. This early research and planning stage is often called discovery. Design screens after the team understands the task; otherwise, a new interface may simply hide the old confusion.

Decide whether to buy, configure, integrate, or build

Custom development is one option among several. Existing software may already solve much of the problem. Configuration may adapt it sufficiently. Integration may connect systems that are individually useful but currently disconnected. A custom application becomes more compelling when the workflow or product experience needs meaningful control that these alternatives cannot provide.

Compare options using the same requirements. Include licensing, setup, migration, integrations, ongoing administration, support, data access, and exit costs. A low subscription fee can become expensive when every exception requires manual work. A custom build can become expensive when it recreates ordinary functions that a maintained product already provides.

Consider where the business needs differentiation. A distinctive service experience may deserve custom design. Password reset, file storage, and payment processing often benefit from established components with clear responsibilities. The goal is not to write the largest amount of original code.

Ask what happens if volume doubles, a vendor changes its pricing, or the business needs to export its records. Review whether critical rules can be represented accurately and whether staff can operate the system without specialist intervention for routine changes.

Write down the options, assumptions and tradeoffs. Configuring an existing product can be a good outcome. So can a small custom addition to a reliable service. Ask the supplier to explain why its choice fits the problem.

Make the first version small but complete

An MVP should let people complete one useful task and help the team answer a clear question. Reduce the number of features, not the basic safety or reliability of the task. A booking service still needs correct availability, permissions, confirmation and a way to handle failure.

Choose one primary user journey. For a membership service, that might mean discovering the offer, registering, paying where applicable, accessing the promised service, and getting help. The first release may omit referral programmes or advanced recommendations, but it should not leave paid members unable to recover access.

Write the question the first release should answer. Can customers complete a request without help? Do staff receive enough information to act? Do people return to use the service? Use that question to choose what to measure and who joins the pilot.

Separate must-have requirements from assumptions that can be tested manually. A staff-operated approval step may be suitable for an early pilot if it is disclosed and reliable. Pretending that a manual process is fully automated creates misleading expectations and obscures the learning.

Agree what the first release should help you decide: continue, change the approach or stop. Set a review date and the evidence needed. Do not keep funding incomplete features simply because work has started.

Create requirements that can be demonstrated

A requirement such as “the app should be easy to use” expresses an intention, but it is difficult to accept objectively. Translate it into observable behaviour. A user should be able to locate the current request status, understand the next step, and correct a permitted detail without contacting support.

For each important workflow, specify the starting state, user role, action, expected result, and exceptions. Include which system stores the authoritative record. Explain whether an action can be reversed and who is permitted to reverse it.

An illustrative approval requirement might say that a reviewer can approve a complete request, that the application records the reviewer and time, and that the submitter receives the agreed notification. It should also say what happens when required information is missing, the reviewer lacks authority, or the notification fails.

Keep a decision log for unresolved questions. Record the owner and deadline rather than allowing developers to guess. Where a temporary assumption is necessary, label it and explain the risk.

Plan content and support alongside code. Who writes help text? Who answers requests? What does the confirmation message promise? Which languages are needed? A finished interface cannot serve people properly while these decisions remain unanswered.

Prototype the difficult decisions before coding everything

A prototype is an early model used to test a design. It may be a simple clickable sequence. Use it to answer a specific question before building the full software, such as whether someone understands a booking status or finds the right form.

Recruit people who resemble intended users through appropriate, consent-based methods. Give them a task and observe how they proceed. Avoid explaining the design while testing it. If users need the designer to narrate the next step, the interface may not yet communicate clearly.

Focus on uncertainty. Can people distinguish two service options? Do they understand why a field is required? Can a reviewer find the information needed to approve a request? Does a customer know whether a submission succeeded?

Test the content with the interface. Placeholder text hides real problems such as long names, unfamiliar terms, incomplete explanations, and translation length. Use realistic but non-sensitive sample records.

Document findings as decisions. A useful outcome might be removing an unnecessary field, changing a status label, or exposing a clearer help route. It need not be a larger feature list. The prototype should reduce uncertainty about the first release, while leaving technical validation to the engineering work. A clickable screen does not prove that an integration, security control, or payment flow is feasible.

Choose web and mobile platforms from user needs

A responsive web application can serve many tasks without requiring installation. It may be suitable for customer portals, booking, internal approvals, and services used occasionally. A mobile application can be justified by device features, offline requirements, frequent use, or a product experience that genuinely benefits from installation.

Define the necessary capabilities before choosing the platform. Does the service require background location, reliable offline work, camera workflows, push notifications, or integration with a device ecosystem? Are these essential at launch, and what privacy or support responsibilities do they introduce?

Consider the audience’s devices and connectivity. A staff tool used on shared low-cost phones needs different testing from a desktop dashboard. A customer-facing application should not assume that every person has a new device, unlimited data, or the willingness to install another app.

Include distribution and maintenance in the decision. App-store submission, release review, supported operating-system versions, crash monitoring, and update adoption are ongoing responsibilities. A web application also requires browser testing, hosting, and secure deployment; neither option is maintenance-free.

If several platforms are proposed, ask which code and design can be shared and where platform-specific work remains. Cross-platform tooling can reduce duplication, but it does not eliminate accessibility, integration, or device testing. The business should understand the support commitment it is accepting.

Plan how records fit together

Data design determines what the application can represent reliably. Identify the core entities, their relationships, and the rules that must always hold. A customer, organisation, request, booking, payment, and approval may be connected without being the same thing.

Avoid storing important business distinctions only in free-text notes. If a request can be pending, approved, rejected, or cancelled, define the states and permitted transitions. If several staff members can act on a record, define how conflicting updates are handled.

Use stable identifiers rather than names as the basis for relationships. Names change and may not be unique. Record timestamps with clear time-zone handling, and define how dates are presented to users. An appointment time is particularly sensitive to misunderstandings across locations.

Decide which changes need a history. A review record should show who changed what and when, without keeping every personal detail forever. Separate service records from measurement data when they serve different purposes.

Design deletion and archival behaviour deliberately. Deleting an account may interact with invoices, support records, legal retention, or shared organisational data. These decisions need business and legal input, not a generic delete button. Good data modelling makes those responsibilities visible before records accumulate.

Treat permissions as part of the product experience

Authentication answers who the user is. Authorisation answers what that user may do. Both matter, and one does not substitute for the other. A person who successfully signs in should not automatically gain access to every record.

List the roles and actions the system needs. A requester may view their own submissions. A reviewer may act on a defined queue. An administrator may manage configuration without necessarily needing access to all sensitive content. Make these distinctions explicit.

Check permissions on the server, not only by hiding buttons. Test changed record references, downloads, exports and links shared between users. An API is a connection that lets software request data or actions. A hidden screen does not protect an API that still allows the request.

For multi-organisation products, test isolation between organisations. Include users who belong to more than one organisation and those whose membership has been removed. Permission changes should take effect in a defined way across active sessions and connected services.

Design helpful failure messages without disclosing information. A user should know that they cannot complete an action and how to seek help, but the message should not reveal another customer’s existence or details unnecessarily. Review privileged actions, account recovery, invitation flows, and administrator access as carefully as the main customer journey.

Include security in the requirements and tests

Security should appear in requirements, design, development, testing, and maintenance. A final scan cannot repair every earlier decision about data access or trust boundaries. Identify the assets that matter, the people and systems that can reach them, and the consequences of misuse.

NIST’s Secure Software Development Framework describes practices for safer development. OWASP’s Application Security Verification Standard, or ASVS, gives detailed application-security requirements; version 5.0 was released in May 2025. [1][2] Use these to organise checks. Naming a standard is not proof that the software meets it.

Choose security checks that fit the risks. Cover settings, third-party packages, secret keys, incoming data, sign-in sessions, access rights, logs and responses to reported flaws. Record anything excluded and why.

Avoid promises such as “completely secure” or “fully compliant”. Ask for evidence from permission tests, automated checks, package reviews and unresolved issues. Where a specialist penetration test is needed, agree what it covers and how findings will be fixed.

Security ownership continues after handover. Someone must monitor advisories, apply updates, review access, respond to reports, and decide when a feature should be paused. A project with no post-launch security owner is accepting a risk that should be visible in the agreement.

Make connected systems handle failure

Connecting two systems takes more than one successful demo request. Name each system’s owner, check how it verifies access, list the data exchanged and decide which system holds the correct value for each field. Explain how staff will resolve disagreements.

Handle delays, retries, usage limits, expired access, duplicate messages and partly completed work. Use idempotency where available: repeating the same request must not create another booking or charge. Record progress so a failed step can be retried without repeating everything.

For example, an order may be accepted while its confirmation email fails. The application should show the accepted order and retry the notification. It should not invite the customer to submit another order simply because the email did not arrive.

Stripe’s guidance covers duplicate webhooks and signature checks. A webhook is an automatic message from a service; its signature helps verify the sender and message. [3] Follow the chosen payment provider’s current instructions and check payment status on the server. A browser redirect or customer screenshot alone is not enough proof of payment.

Give staff a clear queue or alert for connection failures. It should show what is affected and what is safe to do next. Test recovery while building the connection, before its first live failure.

Plan the move from old records to the new system

Replacing a spreadsheet or older application means moving both records and working habits. Start by understanding what the existing data contains. Identify duplicate entries, inconsistent labels, missing fields, outdated records, and values that no longer match the proposed process.

Map each old field to its new location and record any conversion. List records that cannot be imported safely, with counts and examples for the business owner. Do not silently drop them or invent missing details.

Run a rehearsal on a permitted copy of the data. Compare totals, relationships, key calculations, and representative records. Check files and attachments as well as database rows. Users should be able to locate the information they need after migration.

Agree how to switch systems. Will the old one become read-only? Where will new entries go during the move? How will changes be captured? Decide when to stop or reverse the switch and who may make that decision.

Keep the old system or export for the agreed checking and retention period, with proper access limits. The move is complete when the business can work accurately and account for its essential records, not merely when an import finishes.

Make accessibility an acceptance requirement

Accessibility improves the chance that people can complete the intended task using their preferred or necessary way of interacting. It matters for internal tools as well as public products. Employees may use assistive technology, and customers should not need a particular device or physical ability to reach the service.

Specify an accessibility target and the testing approach. WCAG 2.2 provides testable web-content criteria, including areas such as keyboard access, focus, input assistance, and accessible authentication. [4] A target should be accompanied by evidence and known limitations rather than an unsupported badge.

Use semantic controls, meaningful labels, visible focus, readable contrast, understandable errors, and clear status messages. Avoid making drag-and-drop the only way to complete a task. Allow people to review and correct important information before commitment.

Test with keyboard navigation and relevant assistive technologies. Automated tools can find some issues but cannot determine whether a workflow makes sense or whether alternative text is useful. Include representative users where appropriate.

Accessibility also depends on content. Instructions should explain the task plainly. Error messages should say what happened and how to recover. A technically labelled form that uses obscure terminology can still be difficult to use. Treat inclusive design as part of the product’s everyday quality.

Define performance around actual use

Performance requirements should reflect the task and the audience. A dashboard loading a large dataset, a public enquiry form, and a mobile booking flow have different constraints. Identify the points where delay interrupts work or creates uncertainty.

Set measurable limits for page loads, clicks, API replies and background work. Test devices and networks similar to those customers use. A fast demo on a developer’s laptop does not prove the customer experience will be fast.

Interaction to Next Paint, or INP, measures how quickly a page shows a response after user interactions. Google’s guidance explains how to investigate delays. [5] Also watch people complete the task. A page may load quickly but stall during search, table use or form submission.

Load large record lists in smaller parts. Reuse recent results where appropriate instead of repeating expensive work. Decide how fresh that saved information must be. For example, an earlier availability result must not override the current calendar when a booking is confirmed.

Show useful progress for operations that take time. Prevent repeated submission while preserving a way to recover if a request fails. Performance is partly about speed and partly about helping people understand what the application is doing. Both should be tested before release.

Use AI coding tools with human review

AI tools can help write, investigate, document and review code. They can also produce convincing code that misunderstands a requirement or adds a hard-to-see flaw. The team must understand and check the result.

Define where AI tools may access code and data. Review provider terms and organisational controls. Do not place production secrets or unnecessary customer information into prompts. Use isolated development environments and limited permissions for tools that execute commands.

GitHub’s documentation explicitly cautions that Copilot code review can miss problems and make mistakes, and recommends validating its feedback with human review. [6] A second automated review is useful input, not a transfer of accountability.

Keep code changes small enough to understand. Check the intended behaviour through clear code, useful tests and documentation. Do not accept a large generated change just because the app starts.

Anthropic’s January 2026 research studied people learning a new Python library in a small controlled setting and found tradeoffs in immediate understanding. It does not show that every AI-assisted project is slower or worse. [7] Keep code understanding and independent checks in the development process.

Test AI features for uncertain results

Adding an AI assistant, document extractor, or recommendation feature to an application introduces behaviour that may vary between requests. Define what the feature is allowed to do, which sources it may use, and how uncertainty reaches the user.

Separate AI interpretation from fixed business rules. A model may summarise a request, while ordinary code checks account access and approval limits. Do not let unchecked generated text become a database command, payment instruction or public statement.

Build evaluation cases from the intended task. Include ambiguous inputs, missing information, conflicting sources, unsafe requests, and unsupported languages. Check the final business outcome, not only the wording of the response.

Provide an alternative when the AI cannot help. Users should be able to complete essential tasks through a conventional interface or a human process where feasible. If a model is unavailable, the rest of the application should behave predictably.

Plan ongoing AI costs and supplier changes. A retired model, changed API, usage cap or new data term can affect the feature. Keep versions of its instructions, model settings, document sources and tools. Re-test changes before release.

Test according to risk, not just coverage percentages

Match each test to what it proves. Unit tests check a small piece of logic. Integration tests check connected parts. End-to-end tests follow a full user task. Manual testing can reveal confusing wording and unexpected behaviour that scripted checks miss.

Prioritise the workflows where failure matters. Account isolation, payment state, approval permissions, booking conflicts, and data deletion may deserve more attention than cosmetic variations. Explain which tests protect these behaviours.

Use realistic boundary cases. Include empty datasets, long names, duplicate submissions, expired sessions, missing files, unusual characters, and slow dependencies. Test the user’s recovery path, not only the error response.

A high test-coverage percentage is not proof of quality. A test that repeats the code’s own mistake can still pass. Check that the expected result comes from the agreed requirement.

Include regression checks for previously fixed defects. A bug that reached users is useful evidence about where the system’s assumptions failed. Add an appropriate test or control so the same class of problem is less likely to return.

The acceptance report should state what was tested, what remains untested, significant findings, and known limitations. Honest boundaries help the business make a release decision. A vague statement that testing is complete does not.

Ask users to test complete tasks

User acceptance testing should involve the people who will use and operate the software. Give them realistic tasks and a clear way to record issues. Do not ask them simply to click around and approve the project.

Prepare scenarios covering normal work and exceptions. A reviewer should approve and reject requests. A customer should recover access and correct information. An administrator should remove a user, inspect a failed integration, and locate the relevant documentation.

Separate defects from new ideas. A defect fails an agreed requirement. A new idea needs its own priority, cost and timing decision. Keeping them separate makes it easier to see what must be fixed before release.

Agree severity definitions. A broken critical workflow is different from a wording preference. Set an owner, expected response, and retest process for each significant issue. Record any accepted limitation with its consequence.

Use the test session to check staff readiness. Can support answer questions? Are notifications accurate? Does someone own each stalled request? Approval should show that the business can run the service as well as use the screens.

Release in a way the business can reverse

The release plan should state the version, settings, data changes, final checks, monitoring and way to restore an earlier setup. Name who can start or stop the release. Explain the business impact as well as the technical steps.

Separate development, test, and production access. Use controlled deployment processes rather than manual changes that cannot be reproduced. Keep secrets out of source code and document how configuration is managed.

For a pilot, limit exposure to an appropriate group or workload. Monitor the critical journey and compare real outcomes with expectations. Do not expand solely because no complaints arrived; users may abandon the process without reporting a problem.

Restoring old code does not necessarily undo a database change or a request already sent to another service. Plan compatible versions, backups and checks for affected records. Do not assume one button can undo everything.

After release, verify the actual production configuration, links, emails, permissions, and integrations. A feature tested in staging may depend on a different account or setting in production. The first operating period should have clear support coverage and a fast route for reporting defects.

Monitor whether the service is working

Technical monitoring should help the team understand whether the application is providing its service. A server can be healthy while every confirmation email fails. A dashboard can return successful responses while showing stale data.

Track useful events: submitted requests, completed bookings, failed emails, delayed jobs and unresolved connection errors. Link them to the technical details needed to find a cause. Use record references rather than unnecessary personal details in general logs.

Set alerts that have an owner and a response. A threshold without a responsible person is simply another chart. Explain when support should investigate, when engineering should respond, and when the business should pause a feature.

Protect logs as part of the application. They can contain identifiers, message content, or sensitive error details. Define retention, access, and redaction. Avoid logging secrets or full records by default.

Review trends as well as outages. Slower processing or repeated user errors may reveal a design problem early. Monitoring should help staff improve and repair the service without collecting unnecessary information about users or employees.

Plan data use from collection to deletion

Identify why each category of personal data is collected and how it supports the service. Remove fields that have no clear purpose. Explain collection and use in understandable language, with appropriate choices and controls.

India’s Digital Personal Data Protection Act, or DPDP Act, has phased commencement dates. Ask qualified advisers which duties apply to the planned data use and launch date. A generic privacy-policy template does not prove compliance. [8]

Map data across the application, analytics, email, payment provider, support tools, backups, and any AI services. Decide which records are necessary in each system. A customer’s complete profile need not travel with every notification or error report.

Build access, correction, export, retention, and deletion workflows according to the applicable requirements and agreed policy. Test their consequences. Removing a user from the interface should not leave unrestricted copies in reporting exports or forgotten test environments.

Use made-up records for development and testing where possible. If real data is necessary and authorised, limit access and set an expiry. Apply privacy decisions to test systems as well as the live app.

Agree ownership and a usable handover

Source-code handover should be accompanied by the materials needed to operate and maintain the application. Confirm ownership and licensing terms in the agreement, including custom work, third-party components, design assets, and external services.

The client should know which accounts it owns and how administrative access is managed. Domains, hosting, repositories, analytics, email services, and payment accounts should not become accidental dependencies on a departing individual. Use organisational ownership and documented access where appropriate.

Provide setup instructions, settings, release steps, a description of the records, responsibilities for connected services and known limits. Include test results. Explain why important decisions were made, not just where files are stored.

Train the receiving team through practical tasks. Ask them to manage a user, update permitted content, inspect a failed job, find a backup, and contact support. A handover meeting is more useful when people practise the work.

Agree what warranty, maintenance, hosting and new development each cover. State who handles updates, service failures and feature changes. Do not leave these responsibilities to be discovered after launch.

Budget for the application’s working life

Budget for the whole working life: research, design, development, tests, data transfer, content, hosting, monitoring, support, security updates and future changes. Identify charges that rise with users, storage, transactions or AI usage.

Separate known work from uncertain work. A simple form differs from a connection to an undocumented old system. Early research or a technical trial may be the most useful first step when major assumptions remain.

Tie milestones to results people can inspect: agreed requirements, a tested prototype, a working core task, user approval and a complete handover. Make clear what each payment covers.

Discuss tradeoffs openly. A smaller first release may reduce cost and speed learning. Reusing an established component can reduce maintenance. Deferring a second platform may be sensible if the primary journey works well on the web.

Do not base the commercial case on a generic claim that AI makes development dramatically cheaper. DORA’s 2025 research frames AI as amplifying the strengths and weaknesses of the surrounding organisation. [9] Your estimate should reflect the actual requirements, team process, review effort, dependencies, and ongoing responsibilities.

Manage changes as people learn from the product

For each requested change, record the problem, affected users, required systems, cost and pass conditions. This helps the team respond to learning without losing track of quality or budget.

Prioritise according to user and business impact. A small correction to a confusing status may matter more than a visually impressive new dashboard. Review evidence from support, task completion, and user research rather than relying only on the loudest request.

Distinguish urgent fixes from planned improvements. Security and critical service failures need a response path that does not wait for the next feature-planning meeting. Routine improvements can be grouped into manageable releases.

Keep design and technical decisions aligned. A new user role may affect permissions, data, help content, testing, and training. It is not merely another menu option. A new language may affect notifications, legal wording, support, and layout.

Review features that are no longer useful, duplicate another tool or cost too much to maintain. Removing them can make the software easier to use and support.

Follow a booking from requirements to approval

Consider an illustrative application for booking an equipment demonstration. The business needs a visitor to request a suitable slot, a coordinator to confirm availability, and both people to receive an accurate status. The first release does not need payments, loyalty points or a recommendation engine. This is a design example, not a completed client project.

A vague requirement says that users can book appointments. A testable version distinguishes requested, confirmed, cancelled and completed appointments, defines who may change each state, and specifies what happens when availability changes. The coordinator can approve a request; the visitor cannot approve their own. A notification failure must not erase a confirmed appointment.

The prototype should expose the uncertain decision. Show a visitor a requested slot and ask what they believe has happened. If they think the appointment is guaranteed before confirmation, revise the label and next-step explanation. Ask a coordinator to find an unconfirmed request, inspect its details and offer an alternative. Their difficulty reveals a workflow problem before it becomes a database or permissions problem.

Suppose two visitors request the final slot almost together. Check availability when confirming, not only when the page first loads. One confirmed booking and one clear alternative can be correct. Two confirmations for a slot that can serve only one visitor fail the requirement.

User acceptance then follows the same record across roles. The visitor corrects a contact detail, the coordinator confirms a slot, the email service times out, and a support user checks the result. The evidence should show that the booking exists once, the notification can be retried independently, and support cannot access unrelated customer records. After cancellation, the appropriate availability returns and the audit record identifies the change.

The team now has evidence: what users understood, which changes are allowed and how failures are handled. Compare tools against this task, including review effort, defects and ease of maintenance. Generating a booking screen alone does not create a reliable booking service.

A practical acceptance checklist for custom software

Before signing off a first release, review the following with the business owner and delivery team. Each item should refer to an agreed requirement or observable evidence rather than a general assurance.

• The primary user journey works from entry to completion, including the important exceptions.
• Roles, permissions, account recovery, and organisational isolation have been tested.
• Data rules, migration results, audit needs, and authoritative systems are documented.
• Integrations handle failure, retries, duplicate events, and uncertain state safely.
• Accessibility and performance have been checked on representative devices and workflows.
• Significant security findings are resolved or explicitly assessed by authorised reviewers.
• AI features, if included, have evaluation cases, boundaries, and a usable fallback.
• Privacy controls, supplier responsibilities, retention, and applicable legal review are recorded.
• Production deployment, monitoring, backups, and rollback have named owners.
• The client has the agreed source code, accounts, documentation, training, and support terms.
• Known limitations and the next learning or improvement decision are visible.

Lucid Growth Media can help plan and build web apps, mobile apps, internal tools and connections between systems. Tell us who needs the software, what they must finish and what they use today. We can compare what to build or reuse, then agree the tests, ownership and support needed for release.