Posts

Buy, Build, or Both?

Wed, 06 May 2026 11:06:34 Z

You need to open up a new market, cut costs, or automate a process. New software can help solve this problem, but which software meets your needs?

There are three main categories of software: 1) packaged software, 2) software as a service (SaaS), and 3) custom software. This article covers the pros and cons of each and can help you make the right decision for your business.

A useful starting point is to ask whether the process you are trying to solve is a competitive advantage or a commodity. If competitors in your industry all handle the same process the same way, a packaged solution built for that process is probably the right choice. If the process is part of what makes your business different, owning the software that runs it is worth considering.

When is packaged software or SaaS the right choice?

If you want a word processor, email client, or accounting package, it's been done. The products are numerous, mature, and range from free to very reasonably priced.

More and more business software is falling into this commodity space, such as enterprise content management solutions, document management programs, and customer relationship management (CRM) software. These tools have a single purpose and are usually very good at what they do.

Cost wise, buying software is usually cheaper than building custom software. As we'll see later on, there are some caveats to this, but this conventional wisdom is often correct.

This is where most software evaluations end. It meets your requirements and it's cheaper. Make the purchase and move on, right? Well hold on a sec.

There are some risks to packaged software and SaaS that are often overlooked:

They often include modules you don't want and may not be an exact fit for your business. Adding the modules you do want is extra. So is implementing the software and customizing it to fit your business.
They work in functional silos and are usually from multiple vendors. You've got to be sure it will integrate with your other systems.
They may not let you get the data out the way you want it.
Your users may not be as excited about your choice as you are.

Let's take a closer look at these problems and when they may ultimately push your decision to the custom software side.

Get just what you want, no more, no less

Buying software off the rack is the way to go if the package meets all your business requirements. But most of the time, you're buying functionality you don't need and missing functionality you do need. You shouldn't have to change your business to match the software you've just purchased.

The common answer is to have consultants implement a solution and customize it to your business. If the packaged software is a good fit with your requirements, this can work well. You just want the consultants to round out the corners, not rewrite anything. They configure it for your organization and maybe integrate it with some of your existing systems.

But at some point, and it should be pretty soon after the install, the consultants should finish and go home. If they need to stick around for lots of customizations or integrations, you may have already lost the justification for buying instead of building.

Here is the part that catches organizations off guard: those customizations do not stay done. When the vendor releases the next version of the product, every customization has to be reviewed, tested, and often reworked to survive the upgrade. Companies that customize heavily end up dedicating ongoing development resources just to keep their customized version current. You have not bought software at that point. You have rented a starting point and hired permanent staff to maintain the divergence. Custom software costs more upfront, but you are not carrying that ongoing customization debt.

Get deep integration with your existing systems

With packaged software, integration with your other systems ranges from simple to a painful implementation project. For example, if you purchase CRM software and want to load all your existing customers into it, the tool should provide this. Most consultants can do this work quickly. Painful integrations are when you can't get the data out, or you can get it out, but only through a vendor API designed to make full extraction difficult.

If the new system is one piece of a larger process, or if it will be the system of record for your enterprise data, you will have many integration points for data coming into and out of the new system.

With custom software, those integration points are built in because they are part of the original requirements. The software integrates deeply with your current enterprise systems. If done right, the new integration APIs are written in standard ways that are discoverable by any new applications that may come online in the future.

How stable is that vendor? What is your exit plan?

The main value proposition of packaged software is the functionality you get for the price you pay. But that value disappears if the vendor goes out of business, gets acquired, or decides to reprice once you are too embedded to leave easily. And the more you have customized their software, the harder it is to get out. That is not an accident.

SaaS companies are particularly good at this. Low introductory pricing gets you on board. Integration with your other systems and years of data stored in their platform raises your switching cost. At contract renewal, you are negotiating from a weak position.

Many SaaS platforms also have no standard API that competing products support, which means your exit plan involves a migration project, not just a decision. Before you sign a multi-year contract with any vendor, understand exactly how you would get your data out and in what format. More importantly, test it. Run the extraction in a non-production environment and confirm that what comes out is actually usable. Most organizations never do this until they need to, which is the worst possible time to discover that the plan does not work.

With custom software, your business owns the code and the data from day one. There is no vendor to negotiate with and no proprietary format to escape from.

Where is the data stored?

With packaged software, the data is often stored in a proprietary database. Even if it's in a more common format, many vendors will not support direct queries against their data store or will charge extra for reporting access.

If you're using SaaS, your data is in the cloud, on infrastructure you do not control and in a jurisdiction you may not have chosen. For some organizations that is fine. For enterprise clients operating under GDPR, industry-specific data regulations, or internal security requirements, it is a real constraint. Regulators do not accept "the vendor handles that" as an answer when something goes wrong. You are responsible for your data regardless of where it lives.

Custom software puts the data where the organization needs it because storage location, access controls, and compliance requirements are part of the original specification. You can satisfy a security audit because you know exactly what the answers are.

Get user buy-in

The typical IT buying process is to identify the requirements and find the packaged software that best fits. This evaluation is often handed over to a technical person to confirm the software works from an IT perspective.

The problem comes when a package is selected and the users are told that starting next Monday, they will be in training, and the Monday after that, they will be using the new system. If the users haven't helped choose the software, they may reject it or undermine the implementation.

With custom software and custom integration projects, users are involved in requirements early on, and the new system is built to their specifications. They are the most critical stakeholders and can set the tone for a successful adoption throughout your organization.

Conclusion

Software purchase decisions can be as complex as the problems they attempt to solve. Decision makers need to consider the short and long-term costs and risks of buying packaged or SaaS software as-is, buying and customizing it, or going with custom software from the start. The easy answer is not always the best answer when all the risks are considered.

Contact Volare Software for more information about building custom software for your business.

What is custom software?

Tue, 18 Apr 2023 14:20:03 Z

Sure, we sell custom software, but we’ll often be the first to recommend off-the-shelf software if it’s a better fit for your budget, scope, or timeline. Off-the-shelf software is convenient and cost-effective, but sometimes it doesn't quite meet your business's unique needs. In those cases, custom software development may be the better choice.

You might be wondering: what exactly IS custom software? And how does it differ from the social media apps on your phone or the word processor you use at work?

Simply put, custom software is a tailored solution designed specifically for your business's needs. Unlike off-the-shelf software, which is designed to be used by a wide range of individuals and organizations, custom software is built with your specific business processes, requirements, and goals in mind.

Custom software development is similar to building a custom house in many ways. Just as a custom house is designed to meet the specific needs and requirements of its owner, custom software is developed to meet the unique needs and requirements of a business. In both cases, the end result is a solution that is tailored to the owner's exact specifications and reflects their individual style and preferences. Just as a custom house requires a team of architects, builders, and designers to bring the owner's vision to life, custom software development requires a team of developers, designers, and project managers to create a solution that meets the client's specific needs. And just as a custom house can make its owner’s life both more efficient and more beautiful, custom software can add tremendous value to a business, helping to improve productivity, streamline processes, and drive growth.

Think about it this way: the social media apps you use on your phone are designed to be used by a massive audience, with features and functionality that cater to a broad range of users. Your word processor software may have more specialized features, but it's still designed to be used by a wide range of industries and professions.

On the other hand, the inventory management system or fleet management software your company uses is likely more specialized and tailored to your business's specific needs. It may have features and functionality that you can't find in off-the-shelf software, and it's designed to help your business operate more efficiently and effectively.

Custom software can take many forms, from desktop applications to mobile apps to web-based systems. But no matter the form it takes, the goal of custom software development is to create a solution that fits your business like a glove.

So why choose custom software over off-the-shelf solutions? The answer is simple: because it's designed with your business's unique needs in mind, custom software can provide a level of functionality, efficiency, and productivity that off-the-shelf solutions simply can't match. Plus, because it's built specifically for your business, custom software can be more easily integrated with your existing systems and processes, reducing the time and effort required to train your staff on new software.

At Volare Software, we specialize in custom software development, helping businesses of all sizes and industries find solutions that meet their unique needs. If you're tired of using off-the-shelf software that just doesn't quite fit, contact us today to learn more about how custom software can help take your business to the next level.

Ten mistakes to avoid when choosing a custom software development company

Sun, 02 Apr 2023 18:24:49 Z

Here are both versions: EN: markdown### Choosing the right custom software development company

Finding the right software development partner is one of the most consequential decisions in a software project. The wrong choice costs time, money, and sometimes the project itself. We have been building enterprise software since 2009 and have seen these mistakes from both sides of the table.

Mistake 1: Choosing a company that cannot deliver what you need

This sounds obvious, but many companies evaluate vendors on price or availability rather than relevant experience. Ask to see work they have done that is similar to your project. Not just logos on a website, but actual case studies with outcomes. A company that has solved problems like yours will ask better questions and make better decisions throughout the project.

Mistake 2: Choosing a company that cannot support you after launch

Custom software needs maintenance, security updates, and enhancements over time. A vendor that disappears after go-live leaves you with a system that has no one who understands it. Ask how they handle post-launch support before you sign, not after.

Mistake 3: Not checking references and track record

Your development partner will have access to your business processes, your data, and sometimes your customers' information. Check references. Read independent reviews on Clutch or similar platforms. A company with nothing to hide will make this easy.

Mistake 4: Accepting fixed-bid pricing without understanding the risks

If pricing sounds too good or too precise, ask how they handle scope changes. Fixed-bid contracts require all requirements to be defined up front, which is almost never achievable on a real project. When requirements change, and they will, a fixed-bid contract turns your vendor into an adversary arguing over what was and was not in the original specification. We have never worked on a fixed-bid basis because we have never seen it produce a good outcome for the client.

Mistake 5: Not checking the technology stack

Make sure the vendor builds in technologies your organization can support and maintain. If your IT department runs on Microsoft Azure and .NET, a vendor proposing a PHP stack or an unfamiliar cloud platform is creating a long-term support problem. Ask specifically what they will build with and why.

Mistake 6: Underestimating the importance of communication

You will spend months working closely with this team. Poor communication costs more than it saves. Look for a vendor who is responsive during the sales process, has a clear communication plan for the project, and can demonstrate how they keep clients informed. If they are hard to reach before you sign, they will be hard to reach after.

Mistake 7: Not clarifying intellectual property rights

In most US and western European contracts, the client owns everything produced under a work-for-hire arrangement. Do not assume this is the default. Get it in writing, and confirm that the vendor cannot reuse your code, your architecture, or your business logic for other clients.

Mistake 8: Not understanding the development methodology

Ask how the vendor manages a project from kickoff to delivery. Do you see working software regularly, or is there a long quiet period followed by a delivery? We show clients working software at the end of every two-week sprint so there are no surprises. If a vendor cannot explain their process clearly, that is a warning sign.

Mistake 9: Not signing a clear contract

A detailed contract protects both parties. It should cover scope, payment terms, change management, intellectual property, liability, confidentiality, dispute resolution, and post-launch support. If any of these topics are vague in the contract you are reviewing, ask for clarification before signing. Our article on ten disasters to avoid in your next custom software development contract covers what to watch for in detail.

What does custom software development cost?

Mon, 06 Aug 2018 06:00:00 Z

Are you considering custom software development?

Trying to understand what custom software development costs before committing to a discovery call? This article breaks down how custom software is priced, what drives costs up or down, and what you can realistically expect at different project sizes.

How much does custom software development cost?

Custom software development costs depend on team size, project duration, and complexity. Here are typical ranges based on our experience since 2009:

Small projects, such as MVPs, small DevOps engagements, or cloud migrations, start at around €25,000/$30,000 for one full-time developer over one to two months.
Medium projects, covering multi-module web applications, API integrations, or database platforms, run €50,000/$60,000 to €200,000/$225,000 and typically take three to six months with one or two developers.
Large enterprise projects involving multiple systems, complex integrations, or regulatory requirements can exceed €250,000/$300,000 and run six months to two or more years with teams of three to five developers.

What drives the cost up or down?

The biggest cost drivers are team size and duration. Beyond that, the following factors increase complexity and therefore cost:

Third-party integrations. Every API connection to an external system, whether a payment processor, an ERP, or a government data source, adds scope and testing surface.
Legacy system involvement. Migrating or integrating with an existing system that lacks documentation or has inconsistent data requires significantly more time than greenfield work.
Regulatory requirements. Healthcare, finance, defense, and government projects carry compliance overhead that affects architecture decisions, testing, and documentation.
Performance and scale requirements. A system that needs to process thousands of transactions per minute is architecturally different from one handling dozens.
User experience complexity. A consumer-facing application with a polished UI and mobile optimization takes longer than an internal tool used by trained staff.

What is included in the monthly rate?

At Volare Software, our monthly rate covers development, code review, automated testing, deployment, and project communication. We do not charge separately for sprint planning, architecture decisions, or progress reporting. You pay for a team, and that team delivers working software.

Why we do not offer fixed-bid contracts

Fixed-bid contracts require all requirements to be known and documented before work begins. In practice, requirements change on every project, usually significantly. A fixed-bid contract puts your vendor in the position of arguing that your new requirement was not in the original specification. That dynamic is bad for the project and bad for the relationship.

We prefer transparent time-and-materials engagements where we commit to the monthly team cost and provide a range estimate for the total duration. You decide how much scope to take on and can resize the team or pause the engagement at any time.

Delivering the most important software first

We use an agile development process where the highest-value modules are built first. This means you have working, deployable software early in the engagement, which reduces risk and allows you to validate the product with real users before the project is complete.

Unlocking the Power of Custom Software: Is It Worth the Investment?

Tue, 08 Aug 2023 17:49:16 Z

Is custom software development worth the investment?

Custom software costs more upfront than off-the-shelf alternatives. For many organizations that cost is justified. For others it is not. This article explains when custom software development delivers a strong return on investment and when it does not.

When custom software makes financial sense

Custom software is worth the investment when one or more of the following conditions are true:

Your process is a competitive advantage. If the way you operate is what sets you apart from competitors, building software around that process protects it. Off-the-shelf software forces you to work the way your vendor designed it, which means working the same way as every other company using that product.
You are paying for features you do not use. Enterprise SaaS products charge for capabilities built for the broadest possible market. If you are using 20% of a platform and paying for 100% of it, the economics of custom software improve significantly over a three to five year horizon.
You have an integration problem. Many organizations run on a combination of systems that do not talk to each other. Custom software, or a custom API layer, can connect those systems and eliminate the manual work of moving data between them.
You have outgrown your current system. Systems built for a smaller version of your business eventually become constraints. Custom software can be designed to scale with your growth rather than forcing a migration every few years.

When off-the-shelf is the better choice

Custom software is not always the right answer. If your needs are well-served by an existing product, buying is faster and cheaper than building. We will tell you that directly if it applies to your situation. We have done it before.

The clearest signal that off-the-shelf is the right choice is when your process matches what the product does. If you need accounting software, buy accounting software. The market for general business tools is mature and competitive.

How to think about the cost

The upfront cost of custom software is real. So is the ongoing cost of a system that does not fit, of manual workarounds, of data that lives in three different places, and of a competitive process that anyone can replicate by buying the same product you use.

The right comparison is not custom software versus the license cost of an off-the-shelf product. It is custom software versus the total cost of the alternative, including implementation, customization, integration work, training, and the cost of the limitations you accept.

What you can expect from Volare Software

We work on 3 to 12 month engagements with teams of one to five developers. We give you a range estimate after a discovery call and we commit to the monthly team cost. You can scale the team up or down and you can pause the engagement if your priorities change.

Advantages of hiring a business-driven custom software consultancy

Sun, 28 Apr 2024 19:49:26 Z

What makes a custom software consultancy effective?

Technical skill matters in custom software development, but it is not enough on its own. The consultancies that deliver the most value are the ones that understand your business as well as your codebase. This article covers why business understanding is the most important factor when choosing a custom software development partner.

Software that fits your business, not the other way around

Off-the-shelf software is built for the general market. Custom software is built for your specific processes, competitive requirements, and integration needs. But even custom software can miss the mark if the team building it does not take the time to understand how your business actually works.

A business-driven consultancy starts by asking why before asking how. What problem are you solving? What does success look like six months after launch? Who are the people using this system every day? The answers to those questions shape every architecture decision, every feature priority, and every tradeoff made during the project.

Domain experience reduces risk

A consultancy that has worked in your industry or on similar problems brings pattern recognition that a purely technical team does not have. They know which integrations are painful, which compliance requirements affect the data model, and which features sound simple but are not. That experience shortens the discovery phase, reduces the number of costly late-stage changes, and produces software that works the way your business works.

Business alignment throughout the project, not just at kickoff

Requirements change on every project. A business-driven consultancy does not treat that as a problem to be managed through contract language. They treat it as normal and build a process around it. At Volare Software we use agile development with short iterations so that new information and changing priorities can be incorporated without derailing the timeline or the budget.

Long-term thinking over short-term delivery

A consultancy that understands your business thinks about what happens after the project ends. Will the software be maintainable? Can your internal team take it over? Is the architecture flexible enough to grow with your business? These are not afterthoughts. They are design decisions made on day one.

Contact us to discuss your project with a consultancy that has been building business-driven enterprise software since 2009.

How we do agile software development

Sat, 12 Aug 2023 11:43:25 Z

How we do agile software development

We follow an agile software development process that has been refined over more than 17 years of delivering enterprise projects. This article describes how we work, from initial planning through to production deployment.

Stories and bug fixes

The business, usually through a single product manager, is primarily responsible for writing new stories. The content should be enough for the author to remember what they were talking about when asked for details later. Once a story comes up in the work cycle, the delivery team works with the relevant stakeholders to ask questions, work through concrete examples, and produce a design if needed. These conversations highlight the reason for the feature and serve as a strong motivator for the delivery team.

Prioritization

The product manager owns the backlog and sets priorities. The delivery team provides effort estimates to inform those decisions, but the product manager decides what gets built next. This keeps the team focused on business value rather than technical preference.

Iterations

We work in two-week sprints. At the start of each sprint the team reviews the top items in the backlog, confirms the scope, and commits to a set of stories for that iteration. At the end of each sprint we demonstrate working software to stakeholders. There are no surprises at the end of a long project because stakeholders see progress every two weeks.

Tracking work

We use a Kanban-style board to track stories through their stages: ready, in progress, in review, done. Stories do not move to done until they have passed code review and automated testing. This keeps the definition of done consistent and prevents half-finished work from accumulating.

Code review

Every change goes through peer code review before it is merged. Code review is not about catching bugs, though it does that. It is about knowledge sharing, maintaining consistency across the codebase, and catching design problems before they are expensive to fix.

Automated testing

We write automated tests for business logic and integration points. The goal is not 100% coverage for its own sake. The goal is a test suite that gives the team confidence to make changes quickly without breaking existing behavior.

Deployment

We use CI-CD pipelines so that every merge to the main branch triggers an automated build and deployment to the development environment. Releases to production are a deliberate decision, not a manual process. This reduces deployment risk and keeps environments consistent.

What this means for you

You see working software at the end of every two-week sprint. You can change priorities between sprints. You know exactly what was delivered and what it cost. There are no long periods of silence followed by a big reveal.

Contact us to learn more about how we work, or see our agile DevOps automations service for how we apply these practices to DevOps and pipeline work.

Ten disasters to avoid in your next custom software development contract

Sun, 02 Apr 2023 20:39:06 Z

What the contract needs to get right

A custom software development contract is not just paperwork. It defines who owns what, who is responsible for what, and what happens when things go wrong. We have been on enough projects to know that a poorly structured contract creates problems that no amount of goodwill can fix. Here are ten things to get right before you sign.

1. No termination clause

If the vendor is not delivering, can you end the contract? Without a clear termination clause, you may not have the legal authority to do so. Make sure your contract allows you to terminate the engagement if you are not satisfied with the vendor's performance, and be specific about what triggers that right.

2. Ambiguous scope and no defined process

Scope documents are not enough on their own. The vendor will interpret your requirements differently than you intended, and without a defined development process there is no mechanism to catch that early. Your contract should specify how work is broken into iterations, how you review progress, and how changes are incorporated. A process that shows you working software every two weeks is far more protective than a detailed specification document.

3. Vague payment terms

Clear payment terms protect both sides. Ambiguous terms lead to disputes over when payment is due, what constitutes a completed milestone, and what happens if either party is late. Get this down to specifics before the project starts.

4. No intellectual property clause

Who owns the code? In most US and western European contracts, the client owns everything produced under a work-for-hire arrangement. Do not assume this is the default. Get it in writing. Also specify that the vendor cannot reuse your code for other clients.

5. No liability clause

If the vendor delivers faulty code that causes harm to your business or customers, are they responsible? Vendors will want to limit their liability, often to the value of the contract. Make sure any liability cap is high enough to cover your actual risk exposure.

6. No confidentiality agreement

Your vendor will have access to your processes, your data, and sometimes your customers' information. A confidentiality agreement should extend beyond the end of the project, typically by at least a year, and should cover all team members on the vendor's side.

7. No dispute resolution mechanism

If a dispute arises, going to court is slow and expensive. Specify in the contract how disputes will be resolved, whether through binding arbitration, mediation, or some other mechanism. This is far easier to agree on before a dispute than after.

8. No non-solicitation clause

What happens if the vendor hires your staff, or you hire theirs? A non-solicitation clause defines the rules for both sides and reduces the risk of uncomfortable situations during or after the project.

9. No conflict of interest clause

Is the vendor working on the same problem for one of your competitors? A conflict of interest clause requires them to disclose this and gives you recourse if it happens without disclosure.

10. No support agreement

The project is done and the software is in production. A bug appears. Who fixes it? Define the vendor's responsibilities after go-live before you sign, not after. Decide whether you want an ongoing support arrangement, a warranty period, or a handover to your internal team, and document it.

Should you go with an offshore team for your custom software development project?

Sun, 02 Apr 2023 18:25:24 Z

Offshore, nearshore, or local: what actually matters for your project

Cost is usually the first reason companies consider an offshore development team. Rates in India, Eastern Europe, or Southeast Asia can look attractive on paper compared to US or western European rates. But the total cost of a software project is not just the hourly rate. It includes the cost of miscommunication, rework, management overhead, and delayed delivery. This article covers what to weigh when making this decision.

The real cost of offshore development

Offshore teams typically charge less per hour. That advantage erodes when you factor in the following:

Time zone gaps. A 10 to 12 hour difference between a US client and an offshore team means that a question asked at the end of your day gets answered the start of the next. On a complex project, that one-day lag on every back-and-forth adds up quickly.

Communication overhead. Writing specifications clearly enough for a team with a different cultural and linguistic context than yours takes more time and care than most clients anticipate. Misunderstandings that would be resolved in a five-minute conversation can become week-long detours.

Management requirements. Offshore engagements typically require more active project management on the client side. If you do not have a dedicated internal person to manage the relationship, the savings can disappear in your own team's time.

When offshore works

Offshore development works well when the work is clearly defined, repeatable, and does not require much back-and-forth. Maintenance tasks, well-specified feature additions, and QA work are examples where the time zone gap and communication overhead are manageable.

It works less well for projects that involve discovery, evolving requirements, or close collaboration with business stakeholders. Those projects benefit from a team that can respond quickly and communicate without friction.

The nearshore alternative

A nearshore team operates in a similar or overlapping time zone, shares a similar business culture, and communicates without a language barrier. For US clients, that means western Europe or Canada. For Dutch and European clients, that means the Netherlands and surrounding countries.

Volare Software is headquartered in Hilversum, Netherlands, and has been serving enterprise clients in the United States and Europe since 2009. Our team works in CET, which gives full working-day overlap with western Europe and a usable morning overlap with US East Coast teams. We work in English and Dutch and we apply the same agile process to every project, so you see working software at the end of every two-week sprint.

We are not the cheapest option. We are the option that reduces the risk of the project failing or taking twice as long as planned.

Contact us to discuss your project and whether our approach is the right fit, or read more about our custom software development services.

The importance of listening to users during the design process

Sun, 02 Apr 2023 18:46:50 Z

Why user feedback shapes better software

When we are deep in a project, it is easy to become confident in our own assumptions about what users need. The product owner has a clear vision. The developers understand the technical constraints. But neither of those perspectives is the same as sitting with the people who will use the software every day. User feedback during the design process is not a nice-to-have. It is one of the most reliable ways to avoid building the wrong thing.

Users know things you do not

The people who do the work that your software supports have context that no one on the development team has. They know which parts of the current process are painful, which workarounds they have invented, and which edge cases come up every week. That knowledge does not show up in a requirements document unless someone asks for it.

At Volare Software we treat early user conversations as part of the design process, not as a sign-off step at the end. Getting a user in front of a prototype or a working early iteration and watching what they do tells us more in an hour than weeks of specification writing.

Feedback helps you cut scope, not just add to it

One of the most useful things user feedback does is tell you what to remove. Most software projects start with more features than they need. Users consistently tell us which parts of the proposed design they would actually use and which parts sound good in a meeting but do not reflect how they work. That information makes the software smaller, faster to build, and easier to use.

Not all feedback is actionable, but all of it is useful

Some user feedback is clear and direct. Some of it is contradictory. Some of it reflects what a user wants today rather than what they will need in six months. Part of our job is to interpret feedback in context, weigh it against the product goals, and bring recommendations back to the product owner.

We do not treat user feedback as a voting mechanism where the most popular request wins. We treat it as data that informs design decisions made by people who understand both the user's needs and the technical constraints.

When to involve users

The earlier the better. Feedback on a sketch or a low-fidelity prototype is cheap to act on. Feedback on a finished feature is expensive. We try to get some form of user input before major design decisions are locked in, and again after the first working iteration is available.

Five steps to ensure your web app is secure

Tue, 18 Apr 2023 14:27:52 Z

Security should be built in, not bolted on

Web app security is not a final checklist before launch. By the time you are doing pre-launch testing, the decisions that determine how secure your application is have already been made. The architecture, the data model, the third-party services you chose, the way authentication works - all of those were locked in months earlier. This article covers five practices we apply throughout development to keep web apps secure.

1. Encrypt all traffic

Every request between your users and your application should travel over HTTPS. This encrypts data in transit and prevents it being read if intercepted. SSL/TLS certificates are available free through most hosting providers and cloud platforms. There is no good reason to run production traffic over HTTP.

2. Encrypt sensitive data at rest, and do not store it if you do not need it

If your application stores passwords, they should be hashed using a modern algorithm such as bcrypt or Argon2, never stored as plain text or with reversible encryption. For other sensitive data such as payment information or identity documents, the first question to ask is whether you need to store it at all. Data you do not hold cannot be breached. If you do need to store it, encrypt it at the field or row level, not just at the disk level.

3. Run security scans

Automated security scanners test your running application for common vulnerabilities including injection attacks, broken authentication, and exposed sensitive data. Running these regularly, and certainly before any major release, catches issues that code review alone misses. Many are available as part of a CI-CD pipeline so the scan happens automatically on every build.

4. Run static code analysis

Static analysis tools examine your source code without running it. They identify patterns associated with known vulnerability classes: SQL injection, cross-site scripting, insecure deserialization, and others. Integrating a static analysis tool into your development workflow means these checks happen on every commit rather than as a one-off exercise.

5. Check your security headers

HTTP security headers tell browsers how to behave when loading your application. The Content-Security-Policy header restricts which resources the browser will load, reducing the attack surface for cross-site scripting. The Strict-Transport-Security header enforces HTTPS. X-Frame-Options prevents your pages being embedded in iframes on other domains. These are straightforward to configure and make a measurable difference to your application's security posture.

Security is one of the areas where the cost of fixing problems grows significantly over time. Issues caught during development are cheap to fix. Issues discovered in production are not.