# Five Bricks - Site: https://five-bricks.com/ ## SaaS MVP Development: What You Need to Test Before Adding More Features - Link: https://five-bricks.com/blog/saas-mvp-development/ - Published: 2026-10-19T09:57:51+00:00 - Author: 5B_DEV The feature list can keep growing while the most important question stays unanswered: will anyone use this product often enough to pay for it? SaaS MVP development should produce evidence that helps you decide what to fund next. A small application can still be a poor experiment if it tests the wrong assumption. Conversely, some questions can be answered before a production application exists. Start by identifying what would make the business fail even if the software worked perfectly. Perhaps customers will not share the required data. Perhaps the problem occurs too rarely. Perhaps the person who likes the demo cannot approve the purchase. Those uncertainties deserve attention before another feature goes into the backlog. ## **Write the assumption as something you can observe** “Small businesses need better reporting” leaves too much room for interpretation. Which businesses? Who creates the report? What happens when it is late or wrong? What do they do today? Consider a hypothetical reporting product for account managers. A useful assumption might be that managers will connect their existing data and use a generated weekly report in an actual customer meeting. That is more demanding than asking whether they like the dashboard. Separate the assumptions instead of hiding them in one large launch target: * The intended user has a recurring problem worth addressing. * The required data is available and usable. * The workflow produces an outcome the user trusts. * The buyer sees enough value to consider paying. You may need different tests for each. A working integration does not demonstrate demand, and a promising sales conversation does not prove that an integration is feasible. ## **Choose the cheapest credible test for the uncertainty** An interview can reveal how work happens today. A prototype can show whether someone understands a proposed interaction. A manually delivered service can help test whether the output is useful. None is automatically a substitute for a product, but each can answer a narrower question. The [GOV.UK Service Manual describes using prototypes to test risky assumptions during alpha](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works). That is guidance for public services, not a SaaS growth benchmark. The transferable principle is to investigate uncertainty before committing to production scope. If your main risk is whether customers value a report, you may be able to prepare it manually from data they knowingly provide. If your main risk is whether a third- party API exposes the necessary information, a technical investigation is more appropriate than another polished mockup. Be clear with participants about manual work and product limitations. Do not present a founder-operated process as proven automation. Also respect the sensitivity of any real customer data used during testing. ## **Define one complete useful journey** Once a working product is justified, choose the smallest journey that delivers the promised result. For the reporting example, that could mean connecting one data source, generating one report and letting the user correct it before sharing. Supporting five integrations may broaden the market later. It also multiplies the number of ways the first test can fail. Start with the source used by the customers you intend to recruit, provided it gives you a representative test. “Minimum” should refer to the breadth of the product. It is not permission to ignore essential access controls or lose customer records. A real-user pilot needs safeguards proportionate to what it handles, even if the interface is simple. If you already have an AI-built prototype, our [launch-readiness guide](https://five-bricks.com/blog/ai-built-app-launch-checklist/) addresses the technical checks before customers rely on it. Those checks complement product validation; they do not replace it. ## **Decide how you will interpret the pilot before it starts** Write a short test brief with the intended participants, the task and the observation window. Include what would lead you to continue, change direction or stop. Do not copy an activation percentage from an unrelated product. A daily collaboration tool and a quarterly reporting product should not be judged on the same return interval. Choose a window that gives the task a genuine opportunity to recur. Track whether participants reach the useful outcome, whether they return when the need comes back and what assistance they require. Record purchase discussions separately from product usage. A participant who uses a free pilot enthusiastically has not necessarily accepted your pricing. With a small group, individual behaviour can matter more than an impressive-looking percentage. Record the number of participants behind every rate and what made them eligible for the test. Avoid treating friends, staff accounts or people outside the target audience as evidence of demand. ## **Keep manual work visible in the economics** Founder assistance can help an early customer succeed. The danger is forgetting how much assistance it took. Record onboarding calls, data cleaning and corrections alongside software usage. If every report requires substantial expert review, you need to understand whether the proposed price can support that work and whether customers accept the delivery time. This does not automatically invalidate the product. It may point towards a higher- priced service, a narrower audience or a specific automation priority. What matters is making the dependency visible before promising self-service at scale. The same applies to usage-based infrastructure or AI services. Estimate operating costs from the pilot’s actual workflow rather than assuming that each additional customer is almost free. ## **Use feature requests as evidence to investigate** When a participant asks for an export, ask what they need to do with it. The request may reveal that the report must fit an existing approval process. It may also be a preference that has little effect on adoption. Distinguish a blocked task from a suggested improvement. If the user cannot obtain the promised result without the feature, it may belong in the next iteration. If it serves a different customer segment, adding it could make the current test harder to interpret. Keep a record of who requested the change, the problem behind it and whether others encountered the same obstacle. Do not let the loudest participant silently redefine the product. ## **Make the next investment a decision rather than a habit** At the end of the pilot, compare the evidence with the assumptions you started with. Useful outcomes include continuing with a focused release, changing the workflow or deciding that more development is not yet justified. Before approaching a development partner, prepare the target customer, the risky assumption and the journey you want to test. Include what you have already learned, including findings that contradict the original idea. Five Bricks can discuss that scope before a broader build. Share the proposed pilot through our [client intake form](https://five-bricks.com/client-intake/). For budgeting context, the [web application development cost guide](https://five-bricks.com/blog/web-application-development-cost/) explains which requirements change the engineering effort. The estimate should follow the test you need, not determine the question you happen to test. ## Customer Portal Development: What to Include in Your First Version - Link: https://five-bricks.com/blog/customer-portal-development/ - Published: 2026-10-12T09:04:05+00:00 - Author: 5B_DEV A customer asks for the latest document. Someone finds it, checks whether it is approved and emails it over. The next day, another person from the same customer asks for an update. Nothing about either request is unusual. The repeated handling is what makes the process expensive to maintain. A customer portal can give customers direct access to that information. But putting a login screen in front of a folder does not resolve unclear ownership, outdated records or an approval process that lives in someone’s inbox. The useful starting point for customer portal development is a recurring customer task. Choose one that you can support from beginning to end, including the work your own team must do. That gives the first version a purpose and a boundary. ## **Find the request customers should not need to send** Look through recent support messages and account-management conversations. Group the requests by the action the customer wanted to take: download an invoice, check a delivery, approve a document or provide missing information. For each group, ask how often it occurs and why a person currently has to handle it. Sometimes the obstacle is access. Sometimes the information does not exist in a reliable form. A portal addresses the first problem much more directly than the second. Consider a hypothetical service business whose customers approve project documents. The customer needs to see the current version, understand what requires approval and record a decision. A page containing every historical file would technically provide access, but it would leave the important question unanswered: which file am I supposed to approve? Choose a task with an identifiable finish. “Improve customer communication” is too broad. “Let an authorised customer approve the current document and see that their decision was recorded” gives the team something to design and test. ## **Build the customer journey and the staff journey together** For the document-approval example, the customer journey might start with an invitation and finish with a confirmation. Between those points, the customer needs enough context to make the decision without calling the account manager. The staff journey is just as important. Someone must prepare the document, release it to the correct organisation and handle a rejection. If a newer version replaces it, the system must make the status of the old approval clear. A sensible first release could include: * Invitations and account recovery. * A list of relevant projects or requests. * The current document and its approval status. * An approval or rejection action with a recorded history. * A staff view for resolving exceptions and managing access. That is an illustrative scope, not a universal feature list. An order-tracking portal may need no document approval at all. Avoid adding messaging, analytics and online payments simply because other portals have them. ## **Decide which system owns each piece of information** Before designing the dashboard, establish where its information comes from. The accounting system may own invoice status. Your operations software may own delivery dates. Staff may maintain a project milestone in a separate application. The portal should not quietly become another place where people update the same record. If two systems allow changes, define which changes are permitted in each and how conflicts are resolved. Freshness matters as much as availability. A customer seeing yesterday’s delivery status needs to know when it was last updated. If an integration stops working, a reassuring green label can be worse than a clear message that the status is temporarily unavailable. For the first version, ask the development team to identify the source, refresh frequency and failure behaviour for every important field. These decisions affect both the estimate and the customer’s trust in the result. ## **Define access around customer organisations** One customer company can have several users with different responsibilities. A finance contact may need invoices but not project files. A project manager may approve work without being allowed to invite colleagues. Write down who can see and change each kind of record. Include what happens when someone changes employer, leaves a project or loses approval authority. Shared company logins make these distinctions difficult to enforce and obscure who made a decision. [OWASP’s authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege, denying access by default and checking permissions on every request. For a portal, the practical consequence is that hiding a button is not enough. The server must also reject an unauthorised request for the underlying document or action. Ask for permission tests covering at least two customer organisations. A valid login should never be treated as permission to retrieve another customer’s records. ## **Make exceptions visible instead of forcing customers to guess** A first version does not need to automate every unusual case. It does need to tell people what happened and how to proceed. Suppose a customer approves a document just as a staff member replaces it. Should the old approval still count? The answer belongs to the business process, not to a developer’s assumption. Similarly, a failed file upload should not leave the customer wondering whether the team received it. List the exceptions that would create operational confusion: an expired invitation, a duplicate submission, an unavailable source system or a decision made by the wrong person. Decide which the application can resolve and which need a staff member. For cases handled manually, make ownership explicit. A notification sent to a mailbox nobody monitors is not a support process. ## **Check whether customers will actually use it** Invite a small group of suitable customers to complete the chosen task with their normal devices and realistic information. Watch where they hesitate. Do not start by giving them a tour that explains every screen. For a portal replacing status emails, track successful self-service checks alongside the relevant support requests. For approvals, look at completed decisions and the reasons people still need help. Login counts alone say little about whether the portal is useful. Keep a route for customers who cannot complete the task online. Their questions may reveal missing information or a workflow that is not ready for self-service. A portal that merely moves work from your inbox into your customer’s inbox has not solved much. ## **Check existing capabilities before commissioning a separate application** Your current CRM, commerce platform or service-management tool may already offer customer access. Test it against the actual workflow before deciding to build separately. Pay particular attention to organisation-level permissions, integration limits and the effort required to keep information current. A custom portal becomes more relevant when the workflow crosses several systems or depends on rules the existing product cannot support cleanly. Our [custom versus off-the-shelf software guide](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) explains how to assess that wider decision. To discuss a portal with Five Bricks, bring one recurring customer request, the systems holding the information and the roles that need access. Use the [client intake form](https://five-bricks.com/client-intake/) to describe that workflow. It is a more useful basis for a first-version discussion than a list of dashboard features. ## Software Project Rescue: Should You Fix, Rebuild or Change Developers? - Link: https://five-bricks.com/blog/software-project-rescue/ - Published: 2026-10-08T07:31:37+00:00 - Author: 5B_DEV Your launch date has slipped again. The team says the application is nearly finished, but you still cannot complete a customer journey without finding a problem. Before committing more money, you need a clear account of what works and what remains unfinished. Software project rescue begins by establishing what exists and what prevents it from working. Before approving more development or a complete rewrite, ask for evidence about the product’s current behavior, code, data and deployment process. The review may point to a few repairs or reveal that one component needs replacing. It may also expose problems with scope or the way work is being managed. Establish the cause before deciding whether to change teams. ## **Recognize the signs that a project needs an independent review** One missed estimate does not establish that a project is failing. More serious patterns include repeated regressions, demonstrations that cannot be reproduced and an inability to explain what is required for launch. Watch for these symptoms: * Features look complete individually but fail when used together. * The latest code cannot be built or deployed by anyone outside the current team. * Fixing one area regularly breaks another. * Progress reports describe activity without showing working customer journeys. * The business lacks access to essential repositories, hosting or service accounts. * Nobody can distinguish launch blockers from requests added after the original scope. Use these symptoms to frame the review. For example, if nobody else can deploy the application, ask the reviewer to identify the missing access, configuration or instructions. That gives you a specific problem to resolve. ## **Establish access and preserve the current state** Confirm that authorized business representatives can access the source repository, hosting, domain administration, database backups and relevant third-party accounts. Record which organization owns each service and who can grant access. Preserve a copy of the current code and data before substantial changes. Document what is running in production and whether it matches the repository. Have a developer verify that a backup can be restored in a separate environment. Coordinate any access changes so they do not interrupt the application. Replacing a team should include an orderly transfer of operational knowledge and credentials through secure channels. ## **Separate product problems from technical problems** ### **Requirements that keep changing** A team may be implementing features correctly while the definition of the product changes every week. More developers will not settle disagreements about what belongs in the first release. Define one release goal and write acceptance criteria for its essential workflows. Record new requests separately, with an explicit decision about whether each changes the release scope. ### **Code that cannot support reliable changes** Technical problems may include duplicated rules, missing boundaries between components, brittle integrations or inadequate tests around important behavior. The review should identify concrete examples and explain their impact on delivery. Ask the reviewer to reproduce a failure, trace its cause and show what would need to change. A generic statement that the code is “bad” is not enough to justify a rewrite. ### **A delivery process without usable feedback** Some projects have workable code but no dependable staging environment, release procedure or shared definition of completion. Developers cannot get quick feedback, and stakeholders see problems late. The recovery work may involve reproducible deployment, automated checks for critical journeys, smaller releases and clearer ownership. Evaluate whether the current team can adopt that process before assuming a complete team replacement is necessary. ## **Choose between repair, partial replacement and rebuild** ### **Repair when the foundation is usable** Focused repair is appropriate when the main product behavior is sound and problems can be isolated. Examples include an unreliable integration, missing permission checks or a customer workflow with a small number of reproducible defects. Agree on the behavior being repaired and how it will be verified. Avoid turning a recovery phase into an open-ended cleanup of every imperfect line of code. ### **Replace components when one area blocks progress** A difficult billing module or tightly coupled reporting feature may be replaced while the rest of the application stays in use. This reduces the amount of change customers experience at once, but it adds temporary integration work. AWS describes gradual replacement through the [strangler fig pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html), in which functionality moves incrementally to a new implementation. That approach can be useful when boundaries are identifiable and both implementations can coexist. It is not appropriate for every project. ### **Rebuild when essential requirements cannot be met economically** Consider rebuilding when the existing design cannot meet an essential requirement or when the estimated repair work exceeds the cost of a replacement. Both estimates must cover the same required functionality. Include data migration, integrations, existing user behavior and operational support in the rebuild estimate. A new interface can conceal substantial replacement work behind it. Money already spent should inform what can be reused, but it should not decide the next investment. Compare the expected remaining cost, uncertainty and time to a useful release for each option. ## **What a software rescue assessment should contain** Ask the reviewer to separate verified launch blockers from improvements that can wait. Each significant finding should explain what failed, how it was tested and what work would resolve it. The report should also explain which code and assets can be retained, what tests were performed and why the proposed recovery approach is preferable to alternatives. Estimates should make dependencies visible, particularly when access or documentation is incomplete. A reviewer who has only inspected the repository cannot confirm that production backups restore correctly. They also cannot establish how a live integration handles failure without testing it. The report should identify what remains unverified and how that affects the estimate. Suppose a client portal works for individual customers but exposes documents across accounts. Its access controls need repair, but the interface and document management features may still be usable. The assessment should explain those boundaries before recommending a complete replacement. ## **Change development teams without losing context** Before the handover, collect setup instructions, architecture notes, known issues, deployment steps and a list of external dependencies. Include the reasoning behind unusual decisions where it is available. Give the incoming team a bounded initial task. They should reproduce the application, verify one important workflow and make a small change through the intended release process. This reveals gaps in the handover before the team commits to a larger roadmap. Agree on ownership of releases during the transition. Two teams making uncoordinated production changes can create new failures while trying to resolve the old ones. If the product uses a CMS, our guide to [hiring CMS developers](https://five-bricks.com/blog/hire-cms-developers/) covers additional selection criteria. For a custom application, prioritize demonstrated experience with comparable systems and an evidence-based recovery proposal. ## **Set a recovery milestone you can verify** Separate the assessment from the implementation estimate when uncertainty is high. After the assessment, define a milestone that produces a usable result, such as a working onboarding and payment flow in a verified staging environment. Require a demonstration and acceptance checks for that milestone. Track unresolved defects and changes to scope alongside expenditure. This makes it easier to decide whether the recovery plan is working before committing to later phases. ## **Discuss your stalled project with Five Bricks** If your project is stuck, [contact Five Bricks](https://five-bricks.com/contact-us/) with a description of the product and the problems preventing launch or further development. Mention whether you have repository access. We can use that information to discuss what an initial review needs to cover. ## **Frequently asked questions** **Can another development team take over an unfinished app?** Yes, provided access and the available project information allow it. The incoming team should first reproduce the application and assess its condition before promising a completion date. **Is rebuilding always faster than fixing existing code?** No. Rebuilding includes recreating useful behavior, migrating data, reconnecting services and verifying the replacement. Compare both approaches using the same required functionality. **Can a live application be repaired while customers keep using it?** Often, changes can be tested separately and released incrementally. The plan depends on the affected components, data migrations and operational risk. Some work may require a planned maintenance window. ## AI Integration into Existing Software: Use Cases, Costs and Where to Start - Link: https://five-bricks.com/blog/ai-integration-existing-software/ - Published: 2026-10-05T10:26:29+00:00 - Author: 5B_DEV Your team already uses a CRM, a customer portal or an internal application. You want to add AI, but replacing the software would disrupt work that runs well today. The first decision is which task to improve within that existing setup. AI integration into existing software involves more than connecting a model. The feature needs access to the right records and a defined place in the workflow. You also need to decide who checks its output and what happens when it cannot complete a request. Choose a first project you can evaluate with real examples. Assign someone who understands the work to review the results before you extend it to other teams. ## **Choose a workflow with a measurable problem** Start with the task that takes too much effort today. Describe who performs it, what information they use and what happens after they finish. For example, a request to “use AI in customer service” leaves most of the scope undecided. A more useful brief would ask for draft answers to delivery questions, based on order records and the approved shipping policy. A support employee would check each answer before sending it. Record a baseline before implementation. Depending on the task, this might include handling time, correction rate, unanswered requests or the amount of work completed without escalation. Include review time when comparing the new process with the old one. ### **Document processing** AI can help extract information from incoming documents and prepare it for an existing system. A useful starting point could be reading supplier forms and proposing structured records for review. The integration still needs rules for missing fields, contradictory values, duplicate documents and unreadable files. The system should show the source behind important extracted values so reviewers can verify them quickly. ### **Internal knowledge search** Employees may need answers spread across manuals, policies and project documentation. An assistant can retrieve relevant passages and draft an answer with source references. Access permissions must apply before restricted material reaches the model. An employee who cannot open a document should not discover its contents through a generated summary. The feature also needs a process for changed, removed and conflicting documents. ### **Customer support assistance** Begin with suggestions to support staff when the cost of a wrong answer is meaningful. The assistant might classify a request, retrieve relevant account details and draft a response. Distinguish preparing a reply from taking an action. Issuing refunds, changing account details or making commitments to a customer requires explicit business rules and appropriate approval. ## **Decide whether the task needs AI** Some work is better handled by a standard integration. Copying an approved invoice total into accounting software usually needs reliable field mapping and error handling. Interpreting inconsistent descriptions in incoming documents may benefit from a model. Use predictable rules for calculations, permissions and state changes. Use AI where interpreting language or varied inputs is valuable. Combining the two keeps the workflow easier to inspect. Anthropic recommends starting with the simplest approach that works in its [engineering guide to effective agents](https://www.anthropic.com/engineering/building-effective-agents). For your project, compare a model-based feature against a rules-based alternative on the same examples before adding more complexity. ## **How AI connects to an existing application** A typical integration retrieves the data needed for a request and passes it to a model. The application checks the response before displaying it. If the result will change a record, an additional step verifies that the action is allowed and the proposed values are valid. For an order assistant, this means the software retrieves the correct order, supplies relevant shipping information and checks which changes the current user may make. The model should not decide the user’s permissions. The connection method depends on your software. A documented API is usually easier to maintain than automation that operates a changing user interface. Missing APIs, poor data quality and unclear ownership can become larger parts of the project than the AI component itself. OWASP’s [authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) remains relevant here: application access rules should continue to be enforced when an AI feature requests data or performs an action. ## **What drives the cost of AI integration** Separate implementation cost from ongoing operating cost. A model subscription or API bill covers only part of the project. ### **Initial development** An estimate should cover the work needed to understand the process and prepare the data. It should also include connections to existing systems, interface changes and testing. Ask how deployment and ongoing maintenance will be handled. Features that change records or serve several user roles need more detailed permissions and acceptance tests. A draft generator for one internal team has a different scope from an assistant that updates customer accounts across several systems. Ask vendors to explain that difference in their estimates. ### **Recurring operation** Alongside model usage, budget for hosting and any search infrastructure the feature needs. Someone will also need to monitor failures and check quality after updates. Include retries and human review when calculating cost per completed task. Use representative examples to estimate normal and peak usage. Check provider prices and data handling terms at the time of procurement because these can change. ### **An illustrative break-even calculation** Suppose a team processes 2,000 requests per month and the new workflow saves a net three minutes per request, after review and corrections. That releases 100 working hours. At an assumed internal cost of $35 per hour, the capacity has a planning value of $3,500 per month. If ongoing operation costs $700 per month, that leaves $2,800 in monthly capacity value before recovering implementation cost. These figures are assumptions for the example. They do not represent provider prices or a Five Bricks client result. Time saved becomes cash savings only if spending falls; otherwise, the benefit depends on how the team uses the available hours. Repeat the calculation with fewer users and smaller time savings. If the business case no longer holds, use the pilot to test those assumptions before committing to a larger build. ## **Run a pilot with clear acceptance criteria** Select a narrow set of users and representative examples, including difficult and incomplete inputs. Keep an evaluation set separate from the examples used to tune the feature. Decide what counts as an acceptable result. For document extraction, measure critical field accuracy and reviewer effort. For support drafting, measure whether the answer is supported by the available information and how much editing it needs. For actions that change records, verify both permission checks and the final system state. Record failures and make it easy for users to complete the task manually. Expand the pilot after the quality, operating cost and workflow fit meet the agreed criteria. Improvements to the model or prompts should be checked against the same examples before release. ## **What to prepare for a development estimate** Bring a description of one workflow, the systems involved, example inputs and the expected output. Include approximate monthly volume, user roles, review requirements and the consequences of an incorrect result. If an existing tool already meets those needs, compare its configuration and operating costs with custom work. Our guide to [custom applications versus off-the-shelf software](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) can help frame that decision. ## **Discuss your AI integration with Five Bricks** [Contact Five Bricks](https://five-bricks.com/contact-us/) with the task you want to improve and the software your team uses. An example with confidential information removed will help us understand the input, the expected result and the integration work involved. ## **Frequently asked questions** **Can AI be added without rebuilding our application?** Often, a feature can be added through existing APIs or a separate service. The appropriate approach depends on access to data, the application’s architecture and the actions the feature must perform. **Do we need to train our own model?** Not necessarily. Start by testing whether an existing model with appropriate context can meet the requirement. Consider additional training only when evaluation identifies a specific need and suitable data is available. **Can an AI integration run without human approval?** Some bounded tasks can. Decide based on demonstrated reliability and the consequences of mistakes. Drafting an internal summary and changing a customer’s payment details should have different approval rules. ## Built an App with AI? How to Get It Ready for Real Customers - Link: https://five-bricks.com/blog/ai-built-app-launch-checklist/ - Published: 2026-09-28T08:30:58+00:00 - Author: 5B_DEV You have built an app with AI, tested the main screens and shown it to potential customers. They want to use it. Now you need to know whether it will hold up when they bring their own data and start paying. Before you launch an AI-built app, test the situations your demo did not cover. A customer might open an old shared link, cancel a subscription or upload a file the application cannot read. You need to know how the software responds and who will fix it if something goes wrong. You may be able to keep much of the prototype. A technical review should establish what works and which problems need attention before launch. ## **Define what your first customers must be able to do** Write down what a customer needs to accomplish in their first session. In a proposal tool, they might create an account, enter project details and generate a draft. They still need to edit that draft and share it with a client. Test the entire sequence. Repeat the test with interruptions. Close the browser before the draft is saved or disconnect while uploading a file. Check whether the customer’s work survives and whether they can continue without contacting support. Keep the launch small enough to verify. One reliable workflow gives you a clearer basis for learning than several unfinished features. Set aside optional dashboards, additional integrations and visual refinements unless they are necessary for that first journey. ## **Check these areas before accepting real customers** ### **Customer accounts and access to data** A working login screen proves very little about who can access each record. Create separate test accounts for different customers and roles. Check whether a person can open someone else’s document by changing its identifier, use an old shared link after access is revoked or call an administrative action directly. Permissions need to be enforced where data is accessed, including APIs and file storage. Hiding a button in the interface is insufficient. OWASP recommends checking permissions on every request and denying access by default when no permission is granted. See its [authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). ### **Payments and subscriptions** If the product charges customers, test the entire subscription lifecycle. Include failed payments, cancellations, plan changes, refunds and the delay between payment confirmation and account activation. Payment notifications can arrive more than once or in an unexpected order. Stripe documents these behaviors in its [webhook guidance](https://docs.stripe.com/webhooks). Your application should verify notifications and avoid granting duplicate credits or processing the same event twice. Ask the team to demonstrate a successful purchase, a failed payment and a cancellation. After each test, check the account’s billing record and access to paid features. ### **Data recovery and deployment** Ask the developer to restore a backup into a separate environment. Open the restored application and check that customer records and uploaded files are available. Record how long recovery takes and how much recent work would be lost. Also verify that the application can be built and deployed from the repository using documented configuration. Keep production credentials out of source files. Record which services the product depends on and ensure the business has appropriate administrative access to them. A rollback plan should account for database changes. Reverting application code may not reverse a migration that has already changed customer records. ### **Reliability under realistic usage** Test the first release with representative data sizes and simultaneous activity. A dashboard with ten sample records may behave very differently when a customer imports a year of transactions. Identify expensive or slow actions, apply sensible usage limits and make failures visible to the team. Customers should receive a useful explanation when an operation cannot finish, with a safe way to retry where appropriate. If the product itself calls an AI model, test that feature separately from the code used to build it. Include incomplete inputs, irrelevant documents, unsupported requests and unavailable providers. Measure the cost of completing a customer task, including retries and any review needed. ### **Support and ongoing ownership** Someone needs to receive error alerts, respond to customers and decide whether a reported issue blocks further releases. Identify that person before launch. Keep a short operational guide covering deployment, account administration, external services and common failures. If only the original builder knows how the application works, even a modest change can become a handover problem. ## **Decide what to keep and what to rebuild** The fact that an application was built with AI does not determine its quality. Review the actual code, behavior, dependencies and deployment setup. A focused repair may be enough when the core workflow works and the main gaps involve permissions, error handling or tests. A larger refactor may be necessary when the same business rule is implemented differently across several screens or when changes repeatedly break unrelated features. Consider replacing a component when its current design cannot support an essential requirement at a reasonable maintenance cost. A full rewrite needs a stronger explanation: which requirements cannot be met, what can be reused and how the alternative reduces delivery risk. Our article on [the business risks of replacing developers with AI](https://five-bricks.com/blog/why-replacing-software-developers-with-ai-is-risky/) explains the broader ownership issue. For a launch decision, ask for a practical list of verified problems and the work required to resolve them. ## **What a useful launch readiness review should deliver** The review should help you make a release decision. Ask for: * A working demonstration of the main customer journey and its failure cases. * Evidence for each significant issue, including how it was reproduced. * A distinction between launch blockers and improvements that can wait. * A proposed repair scope with assumptions, dependencies and unresolved questions. * Acceptance criteria for confirming that the repairs work. An automated scan alone cannot establish whether the product implements your business rules correctly. Combine code inspection and automated checks with testing of the real application. Consider a booking app that lets two customers reserve the same slot. Its screens may look finished and its unit tests may pass, but it still needs a test that submits competing bookings. This is the kind of business rule a launch review should verify. ## **Budget for the work the review identifies** The remaining cost depends on what the review finds. A team can estimate a few isolated defects more confidently than a project it cannot yet run. Missing repository access or undocumented integrations may require investigation before a repair estimate is useful. Request separate estimates for assessment, essential repairs and optional improvements. Include testing, deployment and support during the initial rollout. Our guide to [web application development costs](https://five-bricks.com/blog/web-application-development-cost/) provides broader planning context. Start with a limited group whose use cases you understand. Agree on what would make you pause the rollout, such as incorrect billing or repeated failures in the main workflow. Resolve those issues before inviting more customers. ## **Discuss your application with Five Bricks** Have a prototype you want to launch? [Contact Five Bricks](https://five-bricks.com/contact-us/) with a short walkthrough and your target launch date. Tell us what already works and where you need help so we can discuss the review and development work required. ## Frequently asked questions **Can an AI-built application become a commercial product?** Yes. The decision depends on the application’s behavior, security, maintainability and operational setup. Its origin alone does not establish whether it is ready to launch. **Do I need to rebuild my prototype from scratch?** Not necessarily. Assess the current implementation first. Targeted repairs or replacement of individual components may address the problems without discarding useful work. **What should I share before a technical review?** Start with a product walkthrough, intended user roles, known issues and a description of the stack and hosting. Arrange repository and environment access securely when needed; do not send production passwords through a contact form. ## What Is an AI Coding Harness? Why the Model Alone Is Not Enough - Link: https://five-bricks.com/blog/what-is-an-ai-coding-harness/ - Published: 2026-09-21T08:37:28+00:00 - Author: 5B_DEV An AI model can generate code. An AI coding harness enables that model to perform software work inside a real development environment. The harness provides the context, tools, execution loop, permissions, tests, and feedback that connect model output to a repository. It may allow an agent to inspect files, run commands, modify code, start an application, read logs, execute tests, and prepare a pull request. It also determines what the agent is not allowed to do. This distinction explains why comparing coding systems only by model benchmarks can be misleading. The model matters, but production results depend heavily on the engineering system around it. ![Software developers working with code on monitors in a real office](https://five- bricks.com/wp-content/uploads/2026/09/image-3-1024x576.png) ## **A Simple Definition of an AI Coding Harness** An **AI coding harness** is the orchestration and control layer surrounding an AI model during software development. It typically performs six jobs: 1. Builds the context the model needs for the current task. 2. Translates model decisions into tool calls and repository actions. 3. Runs the agent through a repeatable planning and execution loop. 4. Restricts access through permissions, isolation, and approval gates. 5. Validates changes with tests, linters, builds, and other checks. 6. Preserves progress and feedback across multiple steps or sessions. The word “harness” is useful because it describes both enablement and control. A climbing harness allows movement while limiting the consequences of a fall. A coding harness gives an agent useful capabilities while keeping its actions observable and bounded. ## **Model, Coding Agent, and Harness Are Not the Same Thing** These terms are often used interchangeably, but they describe different layers. | **Layer** | **Main responsibility** | **Example output** | | AI model | Interprets input and generates a response | A proposed code change or next action | | Coding agent | Pursues a goal over several steps | Searches files, edits code, and runs a test | | Agent harness | Connects the agent to context, tools, execution, permissions, and feedback | A controlled end-to-end development loop | | Engineering system | Defines [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/), CI/CD, observability, ownership, and production operations | A maintainable product and accountable release process | A powerful model inside a weak harness may receive poor context, use tools inefficiently, or stop before verifying its work. A less capable model inside a disciplined workflow may perform better on a narrow, well-specified task. The harness does not eliminate the need for engineering. It is an engineering product itself. ## **The Core Components of a Coding Harness** ![AI coding harness layers connecting human intent, context, tools, model, sandbox, and verification](https://five-bricks.com/wp-content/uploads/2026/09/image-4-1024x576. png) ### **1. Context Construction** A repository may contain thousands of files, years of history, several services, and multiple sources of documentation. Sending everything to the model is expensive and often counterproductive. Sending too little causes incorrect assumptions. The harness must help the agent retrieve the right information at the right time: * repository structure; * relevant source files and dependencies; * [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) and coding standards; * task description and acceptance criteria; * recent changes and version-control history; * test failures, logs, and runtime evidence; * project-specific instruction files. Good context is not simply more context. It is current, relevant, prioritized, and clearly separated from untrusted input. ### **2. Tools and Action Interfaces** The model cannot change a repository by describing a change. The harness exposes tools that turn decisions into actions. Common tools include: * file search, reading, and editing; * shell and package-manager commands; * Git operations; * build systems, linters, and test runners; * browser or UI automation; * issue trackers and pull-request systems; * documentation and API retrieval; * logs, metrics, and tracing systems. Tool design affects reliability. Clear, bounded tools are easier for an agent to use correctly than broad interfaces with ambiguous behavior. Tool output must also be treated carefully because external pages, issue descriptions, logs, and repository files can contain misleading or malicious instructions. ### **3. The Agent Loop** A coding harness repeatedly connects reasoning with evidence: 1. Understand the task and inspect the current state. 2. Form a plan appropriate to the risk and scope. 3. Make a bounded change. 4. Run relevant checks. 5. Interpret the result. 6. Correct failures or reassess the plan. 7. Summarize the completed work and remaining uncertainty. This loop is more important than a single impressive response. Professional development is iterative. The agent must be able to discover that its first assumption was wrong and use test or runtime evidence to change direction. ### **4. Sandboxing and Permissions** A useful coding agent may need to run code, install dependencies, access the network, or interact with deployment systems. Those capabilities create risk if they are unrestricted. A harness should apply least privilege: * isolate work in a dedicated workspace, branch, container, or virtual machine; * restrict writes to the intended project; * limit network access and external destinations; * keep secrets outside the agent’s readable context; * require approval for sensitive or irreversible actions; * record commands and changes for review; * separate development access from production access. Sandboxing is not merely a safety feature added after implementation. It defines the boundary within which useful autonomy is possible. ### **5. Verification and Feedback** The harness needs objective signals that are harder to satisfy accidentally than a conversational instruction. Examples include: * unit and integration tests; * type checking and linting; * security and dependency scanning; * build verification; * browser-based acceptance tests; * performance budgets; * architectural dependency rules; * code review and approval policies; * production logs, metrics, and traces. Passing checks does not prove the feature is correct if the checks are incomplete. A dangerous pattern is asking the same agent to implement sensitive behavior, write all tests for that behavior, and declare success without independent criteria. Strong teams define invariants that apply regardless of how the code is written. Examples include “every administrative action requires authorization,” “API inputs are validated at the boundary,” or “changes cannot introduce dependencies between these [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) layers.” The harness then makes those rules executable. ### **6. State, Memory, and Long-Running Work** Complex work may span hours, multiple context windows, or several agents. The harness needs a way to preserve useful state without allowing stale or untrusted information to silently control future work. Useful artifacts include: * a written implementation plan; * a list of completed and remaining tasks; * test results; * a concise decision log; * commits or checkpoints; * reproducible startup and verification commands; * links to relevant issues and pull requests. The goal is not perfect conversational memory. It is durable, inspectable project state that a developer or another agent can verify. ## **Why the Same Model Produces Different Results** Businesses often evaluate tools by asking which model is “best at coding.” That question is incomplete. Results can change significantly based on: * how the task is decomposed; * which files are retrieved; * whether [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) rules are explicit; * whether the agent can run the application; * how fast it receives test feedback; * which actions require approval; * whether failures are visible through logs and traces; * how much irrelevant information occupies the context; * whether progress survives a long session; * how quality is evaluated before merge. OpenAI’s published harness-engineering experience describes engineers shifting toward specifying intent, building tools, exposing runtime evidence, and creating enforceable feedback loops. Anthropic’s work on long-running agents similarly emphasizes incremental progress, persistent artifacts, and reliable verification rather than asking a model to build an entire application in one attempt. The lesson is vendor-neutral: dependable agentic development is a systems problem, not only a model-selection problem. Research published in 2026 helps quantify why this systems layer matters. An NBER study using data from more than 500,000 GitHub developers found that autonomous coding agents were associated with a cumulative 240% increase in commits, but only an 80% increase in projects and a 30% increase in releases. Generating changes scaled much faster than shipping complete software. A harness addresses that gap by connecting generation to review, integration, testing, and release controls rather than treating the commit as the finished product. A controlled 2026 IEEE study found that AI-assisted participants achieved more than twice the median task completeness, while scoring 12.5% lower when answering technical questions about the code they had produced. That does not argue against coding agents. It argues for workflows that require explanations, independent checks, small reviewable changes, and clear human ownership. Security research published in 2026 found that newer models could detect and repair roughly 75-80% of the examined vulnerabilities when explicitly prompted, but they still missed issues and sometimes gave incorrect conclusions confidently. A harness turns that limitation into an engineering requirement: model review should be supported by static analysis, tests, policy checks, and qualified human review rather than trusted as the final authority. ## **A Reference Workflow for AI-Assisted Development** ![AI coding agent loop from inspect and plan through implement, test, review, and feedback](https://five-bricks.com/wp-content/uploads/2026/09/image-5-1024x576.png) A practical harness workflow can look like this: | **Stage** | **Agent responsibility** | **Human or system control** | | Scope | Restate the goal and identify affected areas | Product owner confirms acceptance criteria | | Inspect | Search code, history, documentation, and tests | Context boundaries prevent irrelevant or sensitive access | | Plan | Propose a sequence of bounded changes | Developer reviews high-risk assumptions | | Implement | Modify code in an isolated branch or workspace | Permissions restrict the blast radius | | Verify | Run tests, linting, builds, and application checks | Independent CI and security policies enforce standards | | Review | Explain changes, tradeoffs, and unresolved risk | Human or separate review agent challenges the result | | Release | Prepare a traceable deployment artifact | Approval, monitoring, and rollback controls remain in place | This workflow can be shortened for a low-risk documentation change and strengthened for authentication, payments, regulated data, infrastructure, or production migrations. The control level should follow business impact. ## **What a Harness Cannot Solve by Itself** A good harness improves reliability, but it cannot compensate for every organizational weakness. It cannot define a coherent product strategy when stakeholders disagree. It cannot create meaningful acceptance criteria from a vague request without making assumptions. It cannot guarantee security when the organization has no threat model. It cannot keep [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/) clean if no boundaries exist. It cannot determine whether a feature creates customer value from code alone. Most importantly, it does not create accountability. People still decide what the agent may do, which evidence is sufficient, and when a change is ready for customers. This is why [replacing engineers with access to a coding model](https://five-bricks.com/blog/why-replacing-software-developers-with-ai-is-risky/) is a false economy. The safer and more productive approach is to let engineers design and operate the harness that multiplies their capabilities. For the business perspective, read **Why Replacing Software Developers with AI Is Risky for Business** at `/blog/ why-replacing-software-developers-with-ai-is-risky/`. ## **How to Evaluate an AI Coding Harness** Before adopting a platform or building an internal workflow, evaluate it across five areas. ### **Context Quality** Can the system find relevant code and instructions without exposing unnecessary secrets or flooding the model with unrelated information? ### **Tool Reliability** Are tools explicit, observable, and limited in scope? Can commands be reproduced by a developer outside the agent session? ### **Security Boundaries** Can the agent work in isolation? Are network access, credentials, production systems, and destructive actions appropriately restricted? ### **Verification Depth** Can the agent run the real build, tests, and application? Are security, [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/), and performance controls enforced independently? ### **Operational Fit** Does the workflow integrate with the team’s repository, issue tracking, code review, CI/CD, monitoring, and incident response? Can the organization measure outcomes rather than demonstrations? ## **Building Harness-Friendly Software** AI agents work better when a codebase is understandable and feedback is fast. Many of the practices that help agents also help human developers: * keep modules focused and boundaries explicit; * store important project rules close to the repository; * make local setup reproducible; * maintain fast, deterministic tests; * provide clear error messages and structured logs; * automate formatting and static analysis; * keep changes small and reviewable; * document architectural decisions and operational procedures; * make deployments observable and reversible. This is an important strategic benefit of adopting AI responsibly. The effort to make a system legible to agents often exposes weaknesses that were already slowing the engineering team. ## **Start with a Bounded Workflow** A business does not need a fully autonomous software factory to benefit from harness engineering. A sensible first implementation is one repeatable, low-risk workflow such as: * investigating a bug and proposing a patch; * upgrading approved dependencies; * generating and validating routine tests; * updating documentation after an API change; * refactoring code under existing test coverage; * preparing a pull request for human review. Define the inputs, permissions, expected artifacts, automated checks, escalation conditions, and owner. Measure cycle time, review effort, defect rate, and successful completion. Expand autonomy only when evidence supports it. ## **The Harness Turns Capability into Engineering Work** The AI model is important, but it is not the complete development system. Reliable results come from the interaction between model capability, repository context, well-designed tools, controlled execution, objective verification, and engineering judgment. For businesses, this means AI adoption should be treated as an engineering transformation rather than a software subscription. The goal is not to generate the maximum amount of code. The goal is to deliver valuable changes faster while keeping risk, ownership, and maintainability under control. Five Bricks helps companies design and build [modern web applications](https://five-bricks.com/services/) with AI-assisted engineering workflows, automated quality controls, and experienced technical oversight. Contact us if you want to evaluate where coding agents can safely accelerate your product delivery. ## **Frequently Asked Questions** **What is an AI coding harness** It is the software and workflow around an AI model that supplies context, exposes tools, runs the agent loop, controls permissions, preserves state, and validates code changes. **Is a coding harness the same as an AI model** No. The model generates decisions or content. The harness connects those decisions to files, commands, tests, external systems, and safety controls. **Does a coding harness replace developers** No. It can automate implementation and verification steps, but developers and product owners still define intent, [architecture](https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/), risk tolerance, approval criteria, and responsibility for production outcomes. **Why are tests important for coding agents** Tests provide concrete feedback that allows an agent to detect and correct failures. They are most useful when acceptance criteria are independent and the agent cannot weaken existing tests merely to make a change pass. **Should an AI coding agent have production access** Not by default. Access should follow least privilege, with isolation, auditability, and explicit approval for high-impact actions. Most coding work can be completed in a development environment and released through existing CI/CD controls. ## Why Replacing Software Developers with AI Is Risky for Business - Link: https://five-bricks.com/blog/why-replacing-software-developers-with-ai-is-risky/ - Published: 2026-09-21T08:36:33+00:00 - Author: 5B_DEV Artificial intelligence can write code, generate tests, explain unfamiliar systems, and complete well-scoped development tasks faster than many teams could a few years ago. That does not mean a business can safely replace software developers with AI. The more useful conclusion is less dramatic: **AI changes how developers work. It does not remove the need for engineering judgment, product understanding, security ownership, or accountability.** A capable developer using AI can move faster and spend more time on high-value decisions. An AI tool operating without competent oversight can produce a large amount of plausible code before anyone discovers that it solves the wrong problem. For business leaders, the real decision is not whether to choose people or AI. It is how to combine experienced engineers, reliable AI tools, and effective controls so that higher development speed produces better business outcomes rather than faster technical debt. ![Software developer reviewing code on a tablet before deployment](https://five- bricks.com/wp-content/uploads/2026/09/image-1024x576.png) ## **AI Can Generate Code, but Software Development Is Larger Than Coding** Code is the visible output of software development, so it is easy to assume that faster code generation makes most of the developer’s role unnecessary. In practice, production software begins long before the first file is changed and continues long after a feature is deployed. Developers and product teams must determine: * what problem the business is actually trying to solve; * which requirements are essential and which can wait; * how the new feature fits the existing architecture; * what data the system may collect, store, and expose; * how permissions, failures, and unusual user behavior should be handled; * how the change will be tested, deployed, monitored, and maintained; * who is responsible when the system behaves incorrectly. An AI model can help with every item on this list, but it does not independently own any of them. It predicts and produces an answer from the context it receives. If the context is incomplete, the output may still look confident and technically polished. That difference matters. A function can be syntactically correct while the feature is commercially wrong. A test suite can pass while testing the wrong assumptions. An integration can work during a demo while failing under real traffic, expired credentials, duplicate events, or partial outages. ## **Why Full Developer Replacement Creates Business Risk** ### **The Wrong Requirement Can Be Implemented Very Efficiently** AI is good at turning clear instructions into implementation. Many business requests are not clear instructions. They contain contradictions, missing edge cases, unspoken operational rules, and assumptions that different stakeholders interpret differently. An experienced developer does not simply accept the request. They ask why the feature is needed, identify conflicts, expose dependencies, and translate business language into testable behavior. Removing that role can make the delivery process appear faster while increasing the probability of building the wrong thing. ### **Architecture Decisions Accumulate** Most architectural problems are not obvious in the first version of a feature. They emerge after months of additions: duplicated logic, unclear ownership, inconsistent data models, unnecessary dependencies, slow queries, and fragile integrations. AI-generated code can follow a strong architecture when the repository makes that architecture explicit. Without those constraints, an agent may optimize for completing the current task rather than preserving the long-term coherence of the system. The result is not necessarily bad code in isolation. It is a codebase made from individually reasonable changes that no longer form a maintainable whole. ### **Security Requires Independent Judgment** AI coding tools can suggest insecure dependencies, mishandle authorization, expose sensitive context, or interact with untrusted repository content. Agentic tools may also run commands, install packages, edit CI configuration, or access external systems. This does not make AI unsuitable for secure development. It means generated changes must pass the same security controls as human-written changes, with additional attention to agent permissions, context exposure, prompt injection, and supply-chain risk. Critical authentication, authorization, payment, privacy, and cryptographic code should not be accepted simply because generated tests pass. The person or team approving the change must understand the threat model and verify the behavior independently. ### **More Output Can Produce More Technical Debt** AI lowers the [cost of producing code](https://five-bricks.com/blog/web-application-development-cost/). It does not automatically lower the cost of understanding, operating, and changing that code. If a team generates features faster than it can review architecture, validate behavior, update documentation, and monitor production, its backlog of hidden risk grows. The business experiences impressive short-term velocity followed by slower releases, regressions, and expensive rewrites. This is why lines of code, number of pull requests, or number of completed tickets are poor measures of AI success. Useful measures include lead time, escaped defects, change failure rate, recovery time, customer adoption, and measurable business impact. ### **Accountability Cannot Be Delegated to a Model** When software blocks an order, exposes customer data, calculates a price incorrectly, or stops a critical workflow, the business cannot ask the model to accept responsibility. Someone must own the decision, investigate the failure, communicate with stakeholders, and make the tradeoff between speed, cost, and risk. AI can support that person. It cannot replace organizational accountability. ## **The Evidence Is More Nuanced Than the Headlines** Research published in 2026 makes the business case more precise. Modern AI tools can increase coding output dramatically, but the increase becomes much smaller as work moves from generating code to releasing software that people actually use. An NBER working paper, revised in September 2026, combined AI usage telemetry with data from more than 500,000 GitHub developers. It reported cumulative increases of approximately 30% in commits for autocomplete tools, 180% for interactive coding agents, and 240% for autonomous coding agents. Yet the 240% increase associated with autonomous agents fell to about 80% when measured as projects and 30% when measured as releases. The researchers concluded that human work remains strongly complementary to AI: review, coordination, product decisions, integration, and release processes can become the new bottlenecks. A 2026 quasi-experiment involving programmers at Ant Group found a 22% increase in completed tasks, even after the researchers used task-based measures rather than relying only on lines of code. Most of the gain came from time saved elsewhere in the workflow, not from directly accepting AI-generated code. The effect was stronger for junior and entry-level programmers and more limited for senior developers. This supports a practical interpretation: AI creates leverage, while the developer still determines how that leverage is used. Productivity also has a comprehension tradeoff. A controlled study published in IEEE Transactions on Software Engineering in 2026 found that participants using AI completed more than twice as much of the assigned tasks by the median measure. However, their ability to answer technical questions about the code was 12.5% lower. Faster completion is valuable, but a business still needs engineers who understand the implementation well enough to maintain it, investigate failures, and make the next change safely. The quality evidence points in the same direction. A 2026 peer-reviewed security study found that newer models detected and repaired roughly 75-80% of the examined vulnerabilities, a major improvement over the earlier model tested by the researchers. They still missed issues, sometimes introduced vulnerabilities, and could present incorrect conclusions with confidence. A separate 2026 preprint analyzing 304,362 verified AI-authored commits across 6,275 GitHub repositories found that more than 15% of commits from each examined assistant introduced at least one detected issue, and 24.2% of tracked issues remained in the latest repository revision. Because that study is a preprint and relies on static analysis, its exact rates should be interpreted cautiously, but its operational lesson is sound: higher generation speed must be matched by stronger verification. The 2025 DORA report remains useful organizational context. It describes AI as an amplifier of existing strengths and weaknesses, which is consistent with DORA’s 2026 guidance that faster generation must be supported by clear ownership, small batches, internal platforms, and fast feedback. The early-2025 METR experiment is also worth retaining as a historical baseline: experienced open-source developers working in mature repositories they already knew took longer with that generation of AI tools. It should not be treated as a measure of current frontier agents. Instead, it shows how quickly results can change with the model, interface, task, codebase, and surrounding workflow. The current evidence therefore does not support either extreme. AI is neither ineffective nor an automatic replacement for an engineering team. It is highly effective at increasing implementation capacity, while the harder constraints increasingly move to specification, verification, architecture, integration, release, and ownership. ## **Where AI Makes Developers Faster** Used well, AI can remove substantial friction from software delivery. ### **Prototyping and Exploration** Developers can test an approach, generate an interface draft, explore an API, or compare implementation options before investing in a complete solution. This makes early discovery more concrete and reduces the cost of rejecting a weak idea. ### **Repetitive Implementation** Boilerplate, data transformations, CRUD operations, configuration, test fixtures, and routine migrations are strong candidates for AI assistance. The developer defines the pattern and verifies that generated variations follow it. ### **Testing and Review Support** AI can propose edge cases, generate initial unit tests, inspect a change for inconsistencies, and explain why a test failed. It is particularly useful as an additional reviewer, although it should not be the only reviewer for security-critical behavior. ### **Working in Unfamiliar Code** An agent can search a repository, trace dependencies, summarize modules, and locate the files involved in a workflow. This reduces orientation time, especially when the developer still validates the explanation against the actual code. ### **Documentation and Maintenance** AI can update documentation, generate migration notes, prepare release summaries, and help with systematic refactors. These tasks often receive too little attention because they compete with feature work. The common factor is clear ownership. A developer frames the objective, supplies the relevant context, chooses the constraints, and checks the result. ## **The Better Model: Developer Plus AI** ![AI-assisted development stack showing business intent, engineering judgment, harness, model, and production feedback](https://five-bricks.com/wp-content/uploads/2026/ 09/image-1-1024x576.png) The role of a developer is moving upward in abstraction. Less time is spent manually typing predictable code. More time is spent defining intent, designing boundaries, selecting tools, reviewing changes, evaluating risk, and improving the environment in which AI operates. | **Traditional emphasis** | **AI-assisted emphasis** | | Writing each implementation line | Specifying behavior and constraints | | Searching manually across the repository | Directing and validating repository analysis | | Producing repetitive tests and documentation | Designing meaningful coverage and reviewing generated material | | Performing every mechanical refactor | Defining invariants and verifying automated changes | | Reviewing only human pull requests | Reviewing both human and agent-generated changes | | Measuring coding activity | Measuring delivery quality and business outcomes | This shift can allow a small, experienced team to accomplish more. It does not make experience less valuable. It increases the leverage of good judgment and the cost of poor judgment. ## **The Missing Piece Is the AI Coding Harness** A model alone receives input and generates output. Professional AI-assisted development requires a system around that model: access to the right repository context, safe tools, explicit rules, tests, permissions, feedback loops, and a controlled execution environment. That surrounding system is commonly called an **[AI coding harness](https://five-bricks.com/blog/what-is-an-ai-coding-harness/)**. The harness determines what the agent can see, what it can change, how it runs commands, which actions require approval, how progress is preserved, and how the result is validated. Two teams can use the same underlying model and achieve very different outcomes because one has built a more reliable engineering environment around it. Read our detailed guide, **[What Is an AI Coding Harness? Why the Model Alone Is Not Enough](https://five-bricks.com/blog/what-is-an-ai-coding-harness/)**. ## **A Practical AI Adoption Model for Businesses** ![Four-stage AI adoption path from assistance to selective autonomy](https://five- bricks.com/wp-content/uploads/2026/09/image-2-1024x576.png) Businesses do not need to choose between banning AI and giving agents unrestricted control. A staged adoption model is safer and usually more effective. ### **1. Assist** Use AI for explanations, drafts, documentation, test suggestions, and developer- controlled code completion. Every change follows the existing review and deployment process. ### **2. Delegate Bounded Tasks** Allow coding agents to handle well-scoped issues in isolated branches or sandboxes. Define acceptance criteria, restrict permissions, run automated checks, and require review before merging. ### **3. Automate Repeatable Workflows** Automate tasks such as dependency updates, test maintenance, routine migrations, codebase cleanup, and initial bug investigation. Monitor accuracy, cost, and failure patterns. ### **4. Expand Autonomy Selectively** Grant more autonomy only where the organization has strong tests, clear ownership, observable systems, reversible changes, and reliable incident response. High-impact actions should keep proportionate approval gates. ## **Questions Leaders Should Ask Before Reducing Engineering Staff** Before treating AI as a replacement strategy, ask: * Who converts business goals into precise acceptance criteria? * Who owns architecture across multiple generated changes? * Who reviews security-sensitive code and dependencies? * Can the agent work in an isolated environment with limited permissions? * Are the tests independent, meaningful, and difficult to manipulate? * Can every production change be traced, reviewed, and rolled back? * Who responds when the generated system fails? * Are we measuring business outcomes or merely code output? If these questions do not have clear answers, removing engineering expertise is likely to increase business risk rather than reduce cost. ## **AI Is a Force Multiplier, Not an Operating Model** AI can make software development faster and more accessible. It can help experienced teams ship more, help smaller teams attempt larger projects, and reduce the time spent on repetitive work. But a model does not provide product ownership, architecture, security governance, quality assurance, or accountability by itself. Those capabilities come from people and from the engineering system they design around the AI. The strongest business case is not replacing developers. It is giving good developers better tools, creating faster feedback loops, and focusing human attention on the decisions that determine whether software creates value. Five Bricks combines experienced product engineering with AI-assisted workflows to build [web applications](https://five-bricks.com/services/) faster without treating quality, security, or maintainability as optional. If you are evaluating an AI-enabled product or want to modernize your development process, contact our team to discuss a practical delivery approach. ## **Frequently Asked Questions** **Will AI replace software developers** AI will automate parts of software development and change the skills developers use most often. Businesses will still need people to define requirements, design systems, manage risk, review outcomes, and take responsibility for production software. **Can a business build an application using only AI** A prototype or simple internal tool may be generated largely with AI. Production applications still require clear product ownership, security controls, testing, deployment, monitoring, and maintenance. The level of human engineering oversight should increase with the application’s business impact. **Does AI always make developers faster** No. Research published in 2026 shows large gains in coding activity and task completion, but much smaller gains at the release level. Productivity depends on the task, codebase, tool generation, developer experience, and quality of the surrounding workflow. AI can accelerate implementation while poor context, weak review, or slow delivery processes consume part of that gain. **What tasks are best suited to AI coding tools** Common examples include prototypes, boilerplate, routine tests, documentation, repository search, migrations, refactoring assistance, and initial debugging. Sensitive or irreversible changes require stronger human review. **What is an AI coding harness** An [AI coding harness](https://five-bricks.com/blog/what-is-an-ai-coding-harness/) is the system around a model that manages context, tools, execution, permissions, memory, tests, review, and feedback. It turns raw model capability into a controlled development workflow. ## Custom Web Application vs Off the Shelf Software - Link: https://five-bricks.com/blog/custom-web-application-vs-off-the-shelf-software/ - Published: 2026-09-14T11:29:18+00:00 - Author: 5B_DEV Choose off-the-shelf software when your process is standard, speed matters more than differentiation, and the product meets most requirements without extensive workarounds. Consider a [custom web application](https://five-bricks.com/services/) when the workflow is specific to your business, several systems must work together, or software directly affects your competitive advantage. The decision should not begin with technology. It should begin with the process, the cost of its current limitations, and the degree of control the business needs. This guide compares both options across cost, launch speed, customization, integration, data control, security, and long-term ownership. It also explains when a hybrid approach produces the best result. ![Balance comparing a standardized software product with a modular custom application]( https://five-bricks.com/wp-content/uploads/2026/09/Comparing-a-standardized-software- product-with-a-modular-custom-application-1024x576.webp) ## **The Difference Between the Two Options** Off-the-shelf software is a product designed for many customers. The vendor defines its core features, release schedule, pricing structure, and operating model. Customers configure the product and may extend it through settings, APIs, plugins, or marketplace applications. A [custom web application](https://five-bricks.com/services/) is designed around the requirements of one organization or product. The owner determines the workflows, permissions, integrations, user experience, and roadmap. The application still uses existing frameworks and cloud services; custom does not mean writing every technical component from zero. ## **Custom and Off the Shelf Software Compared** | **Decision factor** | **Off-the-shelf software** | **Custom web application** | | Initial cost | Usually lower | Usually higher | | Time to launch | Days or weeks | Weeks or months | | Workflow fit | Based on vendor’s model | Designed for your process | | Customization | Limited to available settings and extensions | Controlled by product requirements and budget | | Integrations | Depends on vendor APIs and marketplace | Can be designed around required systems | | Data control | Governed by vendor terms and architecture | Greater control over storage, access, and portability | | Maintenance | Vendor maintains the core product | Owner funds maintenance and development | | Roadmap | Vendor controls priorities | Business controls priorities | | Scaling cost | Subscription increases with seats, usage, or features | Infrastructure and development costs increase with usage and scope | | Vendor dependency | High | Shifted toward the development and hosting ecosystem | Neither option is inherently better. The better option is the one that supports the business process at an acceptable total cost and risk. ## **When Off the Shelf Software Is the Better Choice** ### **The Process Is Common Across Many Businesses** Accounting, payroll, email marketing, video meetings, and basic project management are well-served by established products. Building these capabilities from scratch rarely creates an advantage for a small or mid-size business. A mature product also includes years of edge cases, documentation, support, and integrations. Reproducing that breadth can cost far more than a subscription. ### **You Need to Launch Quickly** An existing platform can often be configured in days or weeks. That speed matters when the business must solve an immediate operational problem, meet a deadline, or test whether a new process will work. Buying first can also be a useful learning step. The team discovers which features matter before investing in a custom product. ### **The Requirements Are Likely to Stay Standard** Off-the-shelf software is a good fit when the team can follow the product’s workflow without harming service quality or creating significant manual work. The important test is not whether every preference is supported. It is whether the unsupported requirements materially affect revenue, cost, risk, or customer experience. ### **The Business Cannot Support Product Ownership** Custom software needs an owner who can prioritize work, answer domain questions, review releases, and plan ongoing improvements. If no one can take that responsibility, a managed product may be safer. ## **When a Custom Web Application Makes Sense** ### **Your Workflow Is Part of the Competitive Advantage** Some businesses win because they quote faster, coordinate complex fulfillment, make better use of data, or provide a customer experience competitors cannot match. A generic product may force those companies into the same workflow as everyone else. [Custom development](https://five-bricks.com/services/) is easier to justify when software strengthens a process that customers value or reduces a recurring operational constraint. ### **Employees Depend on Manual Workarounds** Warning signs include duplicate data entry, spreadsheet handoffs, repeated copying between systems, approvals managed in email, and reports assembled manually every week. One workaround is rarely a reason to build software. A chain of workarounds across a high-volume process may be. The business case improves when the time, error rate, or delayed revenue can be measured. ### **Several Systems Need to Work as One** An organization may use a CRM, accounting platform, inventory service, customer portal, and industry-specific database. Off-the-shelf connectors can cover common data flows, but unusual business rules may still require manual reconciliation. A [custom web application](https://five-bricks.com/services/) can become the workflow layer across those systems. It does not always replace them. It can provide one interface, enforce business rules, and send data to the right platform through APIs. ### **You Need Greater Control Over Data and Permissions** [Custom development](https://five-bricks.com/services/) gives the business more influence over where data is stored, how permissions work, how long records are retained, and how information is exported. That control can matter when customers require specific security terms, auditability, or data residency. Control also creates responsibility. The owner must maintain the application, manage access, monitor vulnerabilities, and keep dependencies current. NIST recommends integrating secure development practices throughout the software lifecycle rather than treating security as a one-time launch task. ### **Vendor Limits Are Restricting Growth** A platform can be a good choice at one stage and a constraint later. Common signals include: * per-user or usage fees growing faster than the value received; * a required feature remaining outside the vendor roadmap; * API limits blocking important automation; * reporting that cannot represent the business model; * customers asking for an experience the platform cannot provide; * mergers or new product lines creating workflows the original tool cannot support. The case for [custom development](https://five-bricks.com/services/) should compare the cost of change with the cost of remaining on the current system. ## **The Hidden Costs of Off the Shelf Software** Subscription price is easy to see. The surrounding operating cost is harder to measure. ### **Configuration and Implementation** Enterprise products may require paid onboarding, consultants, data migration, workflow configuration, and staff training. A lower license price does not always mean a low implementation cost. ### **Add-ons and Higher Tiers** Features such as advanced permissions, audit logs, API access, automation, and analytics may only be available in higher plans. Costs can increase with seats, contacts, transactions, storage, or API calls. ### **Manual Work Around the Product** If employees export data to spreadsheets, correct records by hand, or repeat the same step across multiple tools, the subscription price understates the real cost. Calculate the hours spent on those tasks, the cost of errors, and the delay created in the underlying process. ### **Switching and Data Portability** Before selecting a platform, confirm how data can be exported, which formats are available, and whether attachments, activity history, permissions, and relationships are preserved. Migration becomes expensive when important context cannot leave the system cleanly. ## **The Hidden Costs of Custom Software** [Custom development](https://five-bricks.com/services/) also carries costs beyond the initial build. ### **Discovery and Decision Making** The business must define what the application should do. That work requires time from employees who understand the process, even when an agency leads discovery. ### **Maintenance and Operations** The owner pays for monitoring, hosting, backups, security updates, bug fixes, and compatibility with third-party services. A realistic budget includes post-launch support. ### **Roadmap Discipline** Control over the roadmap creates an endless supply of feature requests. Without clear priorities, a custom product can become larger and more expensive without improving the key business outcome. ### **Team Continuity** Documentation, source control, deployment automation, account ownership, and a clear handover reduce dependence on individual developers. Ask how the application can be maintained if the original team changes. ## **Total Cost of Ownership Over Three Years** A useful comparison includes every relevant cost over the same time period. For off-the-shelf software, calculate: * implementation and migration; * subscription fees at expected seat and usage levels; * paid add-ons and integrations; * consulting and administration; * manual work caused by workflow gaps; * expected switching cost. For custom software, calculate: * discovery, design, development, and launch; * data migration and integrations; * infrastructure and third-party services; * maintenance and security; * internal product ownership; * planned enhancements. Do not assume custom software becomes cheaper after a specific number of years. That outcome depends on development cost, subscription growth, maintenance, and the value created by a better workflow. The comparison should use the company’s actual volumes and labor costs. ### **The Hybrid Option** ![Comparison of off-the-shelf, hybrid, and custom software by business fit](https:// five-bricks.com/wp-content/uploads/2026/09/A-practical-hybrid-flow-from-existing- SaaS-through-a-secure-API-to-a-custom-workflow-1024x576.webp) Many businesses do not need a pure build-or-buy decision. A hybrid approach keeps established products for standard capabilities and adds custom software where the workflow is unique. Examples include: * a custom customer portal connected to an existing CRM; * an operations dashboard using data from accounting and inventory systems; * a quoting workflow that sends approved orders into an ERP; * a tailored reporting layer across several SaaS products; * a custom marketplace using a third-party payment provider. This approach can reduce cost and launch time because the business does not rebuild commodity services. It still requires careful integration planning. Vendor APIs, rate limits, authentication, and data ownership become part of the architecture. AWS guidance for SaaS providers reflects a related principle: shared products should support variation through controlled, reusable configuration instead of separate one-off versions for each customer. For a buyer, this means checking whether a vendor’s supported configuration can meet the requirement before commissioning a custom workaround. ## **A Practical Decision Framework** ![Existing SaaS connected through a secure API to a custom business workflow](https:// five-bricks.com/wp-content/uploads/2026/09/Choosing-among-off-the-shelf-hybrid-and- custom-software-1024x576.webp) Score each statement from 0 for not true to 3 for strongly true. | **Statement** | **Score** | | The workflow is specific to how our company competes | 0-3 | | Existing products require expensive manual workarounds | 0-3 | | Several systems must follow custom business rules | 0-3 | | We need control over the product roadmap | 0-3 | | Data, permission, or audit requirements are unusual | 0-3 | | Subscription costs will grow sharply with our expected usage | 0-3 | | We have an owner and budget for ongoing product development | 0-3 | A high score suggests that [custom development](https://five-bricks.com/services/) deserves serious evaluation. A low score suggests configuring an established product first. The score is a conversation tool, not a purchasing formula. One critical security or integration requirement can outweigh several lower-priority factors. ## **How to Evaluate an Off the Shelf Product** Before buying, run a short pilot with real users and representative data. Ask them to complete the actual workflow rather than watching a sales demonstration. Confirm: 1. Which requirements are supported natively. 2. Which require configuration, an add-on, or custom integration. 3. What the product costs at expected usage in years two and three. 4. How data can be exported and migrated. 5. What the API limits and support terms are. 6. How permissions, audit logs, backups, and incident handling work. 7. Whether the vendor roadmap aligns with the capabilities you will need. Record every workaround introduced during the pilot. Those workarounds often determine the total cost more than the feature checklist. ## **How to Scope a Custom Web Application** Start with the business outcome and one core workflow. Define the users, decisions, data, integrations, and exceptions involved in that workflow. The first release should prove that the application improves the process. Secondary dashboards, advanced preferences, and edge-case automation can follow after users validate the foundation. Request an estimate that separates discovery, design, engineering, QA, launch, and ongoing support. If you need budget guidance, review the companion article on ** [web application development cost in 2026](https://five-bricks.com/blog/web-application-development-cost/)**. ## **How Five Bricks Approaches the Decision** Five Bricks provides website development, web applications, e-commerce products, mobile apps, MVP development, and custom CRM or CMS solutions. Because the agency works across strategy, design, engineering, QA, and support, the engagement can begin with the decision rather than an assumption that every problem requires a new application. Discovery should identify whether an existing product, a custom integration, a focused application, or a larger platform best supports the workflow. When [custom developmen](https://five-bricks.com/services/) t is justified, the same findings become the basis for architecture, design, and a phased delivery plan. If your team has outgrown its current software, document the manual work, system limitations, user groups, and required integrations. Five Bricks can help [evaluate the options](https://five-bricks.com/contact-us/) and define a practical next step. ## **Frequently Asked Questions** **Is custom software always more expensive** Custom software usually has a higher initial cost. Over time, the comparison depends on subscriptions, usage, manual work, maintenance, and the value of a better workflow. Use a multi-year total cost of ownership model rather than comparing the build price with one month of licensing. **How long does custom web application development take** A focused first release often takes 8-14 weeks. A platform with several roles and integrations may require 3-6 months or more. Discovery is needed for a dependable estimate. **Can off the shelf software be customized** Often, yes. Configuration, APIs, plugins, automation platforms, and vendor marketplaces can cover many requirements. The limits depend on what the vendor exposes and supports. Heavy customization may create upgrade, reliability, or maintenance problems. **Who owns a custom web application** Ownership depends on the contract. Confirm ownership of source code, designs, cloud accounts, domains, data, and third-party licenses before development begins. **What is the biggest risk of custom software** The largest risk is building more than the business can validate, operate, or maintain. Reduce that risk through discovery, a focused first release, regular demonstrations, documented ownership, and a funded maintenance plan. **When should a business replace an existing SaaS product** Consider replacement when measurable workflow gaps, integration limits, pricing, data requirements, or roadmap dependency create a recurring cost greater than the expected cost and risk of change. ## Web Application Development Cost in 2026 - Link: https://five-bricks.com/blog/web-application-development-cost/ - Published: 2026-09-14T11:10:20+00:00 - Author: 5B_DEV Building a [custom web application](https://five-bricks.com/services/) in 2026 typically requires a budget of **$25,000 to $250,000 or more**. A focused application with one core workflow may sit near the lower end. A multi-role platform with complex integrations, reporting, security requirements, and high traffic can move well beyond the upper end. That range is wide because a web application is not a standard product. The cost depends on what users need to accomplish, how many systems the application must connect to, and how much operational risk the software carries. This guide explains the main cost drivers, realistic project tiers, ongoing expenses, and the questions to answer before [requesting an estimate](https://five-bricks.com/contact-us/). ![Custom web application layers connected to infrastructure and budget planning elements](https://five-bricks.com/wp-content/uploads/2026/09/Estimating-a-custom- web-application-across-design-engineering-testing-and-budget-1024x512.webp) ## **Web Application Cost at a Glance** The following ranges are useful for early planning. They are not fixed quotes. Discovery can move a project into a different tier once the workflows, integrations, and security requirements are clear. | **Project type** | **Typical scope** | **Planning range** | **Typical timeline** | | Focused application | One core workflow, limited user roles, basic administration, one or two integrations | $25,000-$60,000 | 8-14 weeks | | Mid-size business platform | Several workflows, multiple roles, dashboards, payments or third-party integrations | $60,000-$150,000 | 3-6 months | | Complex or enterprise application | Advanced permissions, many integrations, large data volumes, compliance, high availability | $150,000-$300,000+ | 6-12+ months | These figures assume professional product design, engineering, testing, deployment, and project management. A prototype built to test one idea may cost less. A regulated platform or a product expected to serve thousands of concurrent users may cost substantially more. ## **What Counts as a Web Application** A marketing website mainly presents information. A web application allows users to complete tasks and work with data. Examples include: * customer portals; * booking and scheduling systems; * custom CRM or operations platforms; * subscription products; * inventory and order management tools; * reporting dashboards; * marketplaces; * internal workflow automation. The difference matters when comparing estimates. A polished company website with a contact form and CMS is not priced like a platform with authentication, several user roles, approval workflows, billing, audit logs, and real-time reporting. ## **How Complexity Changes the Budget** ![Three levels of web application complexity from focused workflow to integrated platform](https://five-bricks.com/wp-content/uploads/2026/09/Typical-web-application- cost-tiers-based-on-scope-and-complexity-1024x576.webp) The number of pages or screens is a weak measure of application complexity. Ten screens that display static data can be simpler than three screens that coordinate payments, inventory, permissions, and an external API. ### **Focused Applications** A focused application solves one defined problem. It may support a single user type, a straightforward database, basic authentication, and a small administration area. Common examples include a quote request portal, a lightweight scheduling tool, or an internal dashboard that replaces a spreadsheet. The project can remain near the lower cost tier when the workflow is stable and third-party dependencies are limited. ### **Mid-size Business Platforms** A mid-size platform often supports customers, employees, and administrators. It may include role-based access, notifications, file handling, payments, analytics, and integrations with a CRM, accounting system, or inventory service. At this level, product decisions become more important. Teams need to define permissions, error states, data ownership, and the behavior of each integration. Quality assurance also takes longer because one change can affect several connected workflows. ### **Complex and Enterprise Applications** Complex applications may process sensitive information, serve multiple organizations, or support business-critical operations. Requirements can include single sign-on, detailed audit trails, tenant isolation, data migration, advanced reporting, high availability, and formal security controls. Security work should be part of the development lifecycle rather than a final checklist. The NIST Secure Software Development Framework recommends integrating secure development practices throughout the software lifecycle to reduce vulnerabilities and address their causes. ## **Seven Factors That Drive Web Application Development Cost** ### **Product Discovery and Scope** Development becomes expensive when the team starts coding before the business rules are understood. Discovery turns a broad idea into user roles, workflows, priorities, technical constraints, and acceptance criteria. A short discovery phase adds cost at the beginning, but it reduces the risk of building the wrong feature or repeatedly changing completed work. It also produces a more reliable estimate. ### **User Experience and Interface Design** Design costs depend on the number of workflows, device types, and interaction states. A dashboard needs more than an attractive home screen. Designers must account for loading, empty, error, success, permission, and mobile states. Reusable components can reduce implementation time and keep the interface consistent. User testing is particularly valuable when the application changes an established business process or serves people with different levels of technical experience. ### **User Roles and Permissions** Every additional role increases the number of scenarios the team must design, build, and test. A customer, employee, manager, administrator, and external partner may see different data and perform different actions on the same record. Permissions also affect security. The team must decide who can view, create, edit, approve, export, or delete information and what happens when access changes. ### **Integrations and Data Migration** Integrations often create more uncertainty than visible interface work. The cost depends on API quality, documentation, authentication methods, rate limits, data mapping, and error handling. Migrating historical data adds another layer. Old records may contain duplicates, inconsistent fields, or values that do not fit the new data model. A responsible estimate includes time to inspect, clean, test, and reconcile the migration. ### **Backend Architecture and Infrastructure** The backend controls business rules, data storage, integrations, authentication, and background jobs. Architecture becomes more demanding when the application must handle traffic spikes, large files, real-time updates, multiple tenants, or strict recovery requirements. Cloud services make infrastructure easier to provision, but they do not remove architecture decisions. The team still needs monitoring, backups, access controls, deployment automation, and a plan for scaling. ### **Security and Compliance** All production applications need secure authentication, authorization, dependency management, encrypted connections, and protection against common attacks. Applications in healthcare, finance, education, or other regulated fields may require additional controls and documentation. Compliance affects product design, data storage, logging, vendor selection, testing, and operating procedures. It should be identified during discovery because adding it late can require structural changes. ### **Quality Assurance and Launch Readiness** Testing covers more than checking whether a button works. A professional QA plan may include automated unit tests, integration tests, end-to-end scenarios, cross- browser checks, responsive behavior, accessibility, performance, and security review. Google recommends evaluating page experience across Core Web Vitals, mobile usability, secure delivery, and the clarity of the main content. Good scores alone do not guarantee rankings, but a usable and reliable experience supports both users and search visibility. ## **Where the Budget Goes** A typical custom application budget is distributed across several disciplines: | **Workstream** | **What it covers** | **Approximate share** | | Discovery and planning | Requirements, workflows, priorities, architecture | 10-15% | | UX and UI design | Wireframes, prototypes, design system, responsive states | 15-25% | | Engineering | Frontend, backend, database, integrations | 40-55% | | QA and launch | Testing, fixes, deployment, release checks | 15-25% | | Project management | Coordination, demos, documentation, risk management | Included across phases | The allocation changes by project. An internal automation tool may need little visual design but significant integration work. A consumer subscription product may require deeper UX research and a more polished interface. ## **Costs That Continue After Launch** ![Web application development lifecycle from discovery through ongoing support]( https://five-bricks.com/wp-content/uploads/2026/09/Illustrative-allocation-of-a- custom-web-application-budget-1024x576.webp) The launch budget is only part of the total cost of ownership. Plan for: * cloud hosting, storage, email, monitoring, and other infrastructure; * third-party subscriptions and API usage; * security updates and dependency maintenance; * bug fixes and browser or operating system changes; * customer support and operational administration; * analytics, performance improvements, and new features. A common planning approach is to reserve **15-25% of the initial development budget per year** for maintenance and incremental improvement. A stable internal tool may require less. A growing SaaS product may invest much more because development continues after the first release. ## **Fixed Price Versus Time and Materials** ### **Fixed Price** A fixed price works when the scope is stable, the acceptance criteria are precise, and unknowns are limited. It gives the buyer budget certainty, but changes usually require a new estimate or change request. ### **Time and Materials** Time and materials works better for evolving products, complex integrations, and projects where user feedback will shape priorities. The client pays for the capacity used and can adjust the backlog as the team learns. ### **Phased Engagement** Many businesses benefit from a phased model: fixed or capped discovery, a defined first release, and then ongoing development in sprints. This creates a decision point before the largest investment and keeps the product flexible after launch. ## **How to Get a More Accurate Estimate** An agency can provide a useful range faster when you bring clear information. Prepare: 1. The business problem and the measurable result you want. 2. The primary user types and the tasks each user must complete. 3. The systems the application must integrate with. 4. Existing data that needs to be migrated. 5. Security, compliance, and geographic requirements. 6. The target launch window and any hard deadlines. 7. The features that are essential for the first release. Screenshots, sample reports, current spreadsheets, and short workflow recordings can be more useful than a long feature wish list. They show how the work happens today and where the real friction sits. ## **How to Reduce Cost Without Weakening the Product** Start with one valuable workflow. A smaller first release is easier to estimate, test, and improve. It also reveals whether users adopt the product before the team invests in secondary features. Use established services for commodity capabilities such as payments, email delivery, identity, and file storage when they meet the requirements. Custom engineering should focus on the workflow that differentiates the business. Keep one product owner available to answer questions and approve decisions. Delayed feedback creates idle time and rework. Regular demonstrations help stakeholders see working software before assumptions become expensive. Do not remove testing, security, or discovery simply to lower the proposal. Those cuts may reduce the initial quote while increasing operational risk and post-launch cost. ## **Warning Signs in a Web Application Quote** Be cautious when a proposal: * gives one precise price before discussing users and workflows; * omits discovery, QA, deployment, or project management; * lists technologies without explaining why they fit the product; * assumes every integration will work without investigation; * does not define ownership of code, infrastructure, and accounts; * provides no plan for maintenance, monitoring, or handover; * promises an enterprise platform on the timeline of a simple website. A credible estimate states its assumptions and exclusions. It should explain what can change the budget and how the team will handle new information. ## **Planning Your Project with Five Bricks** Five Bricks develops websites, web applications, e-commerce products, and custom business systems. The process starts with research and discovery, followed by architecture, UX and UI design, development, QA, launch, and ongoing support. That sequence is designed to make the estimate more reliable before the largest part of the development budget is committed. It also gives the client regular opportunities to review working software and adjust priorities. If you are planning a custom application, share the workflow, required integrations, and first-release priorities. Five Bricks can review the requirements and prepare an initial scope and budget range. ## **Frequently Asked Questions** **How much does a simple web application cost** A professionally designed and developed application with one focused workflow often starts around $25,000. A small prototype can cost less, while production requirements such as integrations, administration, security, and testing can increase the budget. **How long does it take to build a custom web application** A focused first release often takes 8-14 weeks. Mid-size platforms commonly require 3-6 months. Complex products may take 6-12 months or continue through ongoing releases. **Can AI reduce web application development cost** AI-assisted tools can speed up some research, coding, testing, and documentation tasks. They do not remove the need to define workflows, make architecture decisions, verify security, test integrations, or validate the product with users. Treat productivity gains as part of the delivery approach, not as a substitute for product engineering. **Is a mobile app included in the web application price** Usually not. A responsive web application works in a mobile browser, but a separate native iOS or Android app introduces additional design, engineering, testing, release, and maintenance work. **How much should a business budget for maintenance** A useful starting point is 15-25% of the initial development cost per year. The actual amount depends on usage, infrastructure, third-party changes, security requirements, support expectations, and the pace of new feature development. **What is the first step in getting a quote** Start with a short discovery conversation about the users, workflow, integrations, risks, and desired business outcome. This is enough to identify the likely project tier and the work needed for a dependable estimate. ## UI UX Design Services for Healthcare Applications: Why Good Design Saves Lives - Link: https://five-bricks.com/blog/ui-ux-design-services-for-healthcare-applications/ - Published: 2026-04-02T08:40:13+00:00 - Author: 5B_DEV A poorly designed healthcare app isn’t just frustrating. It’s dangerous. [Studies show](https://pmc.ncbi.nlm.nih.gov/articles/PMC11298029/) that well-designed healthcare platforms can improve patient satisfaction by up to** 60%**, while diagnostic errors linked to clunky interfaces contribute to tens of thousands of preventable deaths each year. In healthcare, design isn’t decoration. It’s a safety net. This guide covers everything you need to know before investing in UI UX design services for healthcare applications. Here’s what’s inside: * Why healthcare UX requires a fundamentally different approach * Key design principles for patient-facing and clinical applications * How to choose the right healthcare UX design partner * HIPAA compliance and security considerations in design * What separates good healthcare design from life-saving design Let’s dig in. The stakes are too high to get this wrong. ## **Why Healthcare UX Needs a Different Approach** Most digital products can survive a mediocre interface. A confusing button on a shopping app might cost a sale. A confusing button on a healthcare app could cost a life. That’s the fundamental difference that makes healthcare UX design an entirely separate discipline from standard UI UX design. Healthcare applications serve diverse user groups with wildly different needs. A 75-year-old patient checking lab results on a patient portal has _nothing_ in common with an ER nurse navigating electronic health records during a critical moment. Yet both users need intuitive interfaces that work under pressure. ### **What Makes Healthcare UX Unique** * **Stakes are higher.** Errors in healthcare systems can directly impact patient safety and patient outcomes. * **Users are diverse.** You’re designing for healthcare professionals, elderly patients, caregivers, and people with disabilities. Diverse user needs demand accessible interfaces that leave no one behind. * **Regulations are strict.** Healthcare regulations like HIPAA add layers of complexity that most industries never face. * **Workflows are complex.** Clinical workflows involve dozens of steps, multiple team members, and sensitive patient data flowing between complex systems. * **Emotional context matters.** Users often interact with healthcare apps during stressful, vulnerable moments. Mental health platforms especially require empathy baked into every interaction. Never design a healthcare product based on assumptions. Deep user research with real users, both patients and medical professionals, is the only way to uncover the pain points that actually matter. ## **Key Principles for Healthcare Design** Whether you’re building a patient portal or a clinical dashboard, the same core principles apply. Good healthcare UI UX design serves two masters: the person _using_ the product and the person whose _life_ depends on it. ### **For Patient-Facing Applications** Patients want simplicity. They want to book an appointment, view health records, or message their doctor without a tutorial. Patient engagement solutions only work when the interface gets out of the way. * **Clarity over cleverness.** Use plain language, not medical jargon * **Minimal steps.** Every extra click increases drop-off. Simplify complex workflows wherever possible * **Accessibility first.** Design for screen readers, low vision, motor impairments, and diverse user groups * **Trust signals.** Transparent privacy policies and visible security indicators build patient confidence ### **For Clinical Applications** Healthcare professionals need speed and precision. They interact with complex health data under time pressure, so every design decision should reduce cognitive load. | **Principle** | **Why It Matters** | | Visual hierarchy | Ensures critical patient data is seen first | | Error prevention | Confirmation steps for high-impact actions protect patient safety | | Customizable dashboards | Lets providers focus on the metrics _they_ need | | Seamless integration | Connects with electronic health records and existing healthcare systems | ### **Universal Principles** Regardless of the audience, every healthcare app design project should prioritize: 1. User-centered design driven by deep user research and usability testing 2. Consistent design systems that scale across platforms 3. Performance optimization for fast load times in high-pressure environments 4. Mobile responsiveness for on-the-go access ## **Choosing the Right Design Partner** ![Healthcare UI UX design wireframes for mobile app development](https://five-bricks. com/wp-content/uploads/2026/03/chart-7-1024x616.webp) Not every design agency understands healthcare. The healthcare sector has unique challenges that generic UI UX design services simply aren’t built to handle. Choosing a partner without deep industry knowledge is a risk you can’t afford. ### **What to Look For** * **Healthcare-specific portfolio.** Ask for case studies from healthcare projects, not just general app design. Look for patient portals, EHR interfaces, telehealth platforms, and medical UX solutions. * **Compliance expertise.** Your partner must understand [HIPAA](https://www.hhs.gov/hipaa/index.html), [HITECH](https://en.wikipedia.org/wiki/Hitech), and other strict regulations that govern healthcare digital products. * **User research capabilities.** The best healthcare design agencies conduct deep user research with real users before sketching a single wireframe. * **Understanding of clinical workflows.** If a designer doesn’t understand how a nurse, doctor, or administrator actually works, the product will fail. * **Strong project management.** Healthcare projects are complex. Your partner needs structured processes and clear communication across cross-functional teams. ### **Red Flags to Avoid** | **Green Flag** | **Red Flag** | | Shows healthcare-specific case studies | Only has consumer app experience | | Discusses compliance from day one | Treats HIPAA as an afterthought | | Conducts user testing with patients and providers | Skips research, jumps to design | | Understands diverse healthcare needs | Designs a one-size-fits-all solution | This is where [**5Bricks brings real value**](https://five-bricks.com/). Our team approaches every project with domain research first, studying the healthcare experience, the users, and the technical landscape before the design and development process begins. For healthcare companies that need a partner who understands both the technology and the stakes, that research-first approach makes all the difference. ## **HIPAA Compliance in Design** In the healthcare industry, beautiful design means nothing if it leaks patient data. Data security isn’t a feature you add later. It’s a foundation you build on from day one. Every healthcare platform that touches sensitive patient data must comply with HIPAA and related healthcare regulations. ### **What HIPAA Means for UX** HIPAA compliance affects how you collect, display, store, and transmit protected health information (PHI). That has direct implications for your UI design: * **Authentication flows.** Multi-factor authentication is essential, but it must be balanced with user satisfaction. Overly complex logins frustrate users and reduce engagement. * **Data display.** Patient data on dashboards and patient portals should be visible to authorized users only. Role-based access controls are non-negotiable. * **Session management.** Automatic timeouts protect sensitive patient data, but they should warn users before logging them out. * **Encryption.** All data in transit and at rest must be encrypted. This is invisible to the user but critical to the system. ### **Beyond HIPAA** Compliance isn’t just about checking boxes. Healthcare organizations operating internationally may also need to meet GDPR, PIPEDA, or other regional standards. Your ux design services partner should understand which regulations apply to your market and build accordingly. **_Pro tip:_** Run a compliance audit _during_ the design process, not after launch. Fixing compliance gaps in a live product is exponentially more expensive and risky than addressing them early. ## **Good Design vs. Life-Saving Design** ![Healthcare UI UX team designing medical app interface](https://five-bricks.com/ wp-content/uploads/2026/03/chart-8-1024x616.webp) There’s a meaningful gap between a healthcare app that “looks nice” and one that genuinely helps improve patient outcomes. Good design is usable. Life-saving design is _invisible_. It works so seamlessly that healthcare professionals never have to think about the interface. They just act. ### **What Good Design Looks Like** * Clean layouts and user-friendly interfaces * Consistent branding and healthcare branding standards * Mobile-responsive pages that adapt across devices * Meets modern user expectations for speed and clarity ### **What Life-Saving Design Looks Like** * A nurse finds critical lab results in **two seconds** because the visual hierarchy guides their eyes exactly where they need to go. * A patient managing a chronic condition gets a proactive nudge from their healthcare app _before_ symptoms escalate. * A telehealth interface adapts to a rural user’s low-bandwidth connection so they don’t lose access to patient care during a critical consultation. * An EHR system prevents a medication error because the UI flagged a drug interaction _before_ the doctor confirmed the prescription. ### **The Difference Comes Down to Research** Life-saving healthcare UI UX design doesn’t happen by accident. It comes from a deep understanding of how healthcare providers and patients actually behave in real- world conditions. It requires user testing in high-pressure scenarios, not just clean lab environments. And it demands innovative solutions that address the diverse healthcare landscape, from large hospital systems to small mental health practices. [**5Bricks understands**](https://five-bricks.com/) this distinction. We don’t just deliver healthcare platforms that meet modern user expectations. We research the domain, test with real users, and build digital solutions that genuinely enhance patient engagement and improve patient care. When the interface disappears and the experience just _works_, that’s when design starts saving lives. ## **Build Healthcare Solutions That Save Lives With 5Bricks** Great healthcare technology doesn’t just look good. It protects patients, simplifies workflows, and helps improve patient engagement at every touchpoint. Whether you’re designing a healthcare website or a full clinical platform, creating user-friendly interfaces is what separates functional healthcare services from forgettable ones. **Key takeaways** * Treat healthcare UX as a safety-critical discipline, not a cosmetic upgrade * Design for diverse users, from patients to providers, with research-backed decisions * Bake HIPAA compliance into your design process from day one * Choose a design partner with real healthcare experience, not just a polished portfolio * Prioritize life-saving clarity over trendy aesthetics [5Bricks builds healthcare solutions](https://five-bricks.com/) grounded in domain research, modern healthcare technology, and real user needs. We handle everything from strategy to post-launch support, so you can focus on what matters: delivering healthcare services that improve patient engagement and genuinely improve lives.