The origins of the disciplined methodology used by CivilCode can be traced to the early careers of the company’s two co-founders: Nicholas Henry and Hugo Frappier. Both were independent contractors whose paths crossed on projects and at industry conferences, notably the annual Ruby on Rails Conference.

In addition to sharing the same opinion of how to use a disciplined approach to develop software, Nicholas and Hugo also discovered that they were both interested in increasing the complexity of the type of projects that they were working on independently.

When technology met opportunity

The future co-founders of CivilCode also agreed that they wanted to use Elixir as one of the key components in their technology stack. When Elixir became available, Nicholas and Hugo started to seriously investigate working together in a structured company to move beyond collaborating independently.

Another contributing factor to the creation of CivilCode was a market need to fill a gap that wasn’t being well served. Small and medium-sized businesses that outgrew their off-the-shelf software required more than an individual developer could provide but weren’t the right fit for a large software consultancy.

Through multiple discussions and their own discovery process, Nicholas and Hugo ironed out their niche: developing custom software to automate business workflows and solve clients’ process problems.

Where the name CivilCode came from

A major component of the work environment and company values that Nicholas and Hugo wanted to create is centred around using a disciplined or “civilized” approach to software development.

From the start, CivilCode has implemented its methodology on all projects.

This methodology includes:

• an in-depth discovery phase that uses story mapping and event storming to clarify user tasks and goals, and reveal the required business processes
• iterative development for continuous delivery of incremental releases
• pair programming for high-quality software
• billing blocks of developer time instead of fixed-price project fees
  devoting one day per week to professional development, research, and contributions to open-source software development projects

How CivilCode is different from a digital design agency

By focusing on building the applications that run a business, CivilCode sets itself apart from digital design agencies that specialize in developing mobile apps and Software as a Service for startups.

When a small or medium-sized business is growing and struggling with off-the-shelf solutions, they require developers that have extensive business workflow expertise. With experience developing software for industries ranging from heavily regulated healthcare to creative digital music creation, the developers at CivilCode are uniquely positioned to solve business-specific workflow problems.

Who benefits most from working with CivilCode

Outgrowing an off-the-shelf software solution is a good problem to have. Established small and medium-size businesses that need custom software to streamline their internal processes are an ideal fit for CivilCode.

When manual processes, wrong tools, and inefficient procedures prevent a company from scaling as it should, custom software applications can open up growth opportunities without increasing administrative headcount. Having control over custom software development is also of great value to CivilCode clients.

Want to learn more about our civilized process? Ask us any questions you have about how we develop custom business applications.

How CivilCode promotes civilized custom software development was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

When Nicholas and I founded CivilCode we transitioned from working individually to collaborating. As CivilCode has grown, we’ve refined our collaborative process to provide an engaging environment that allows us to accomplish more than we could individually. Both isolation and collaboration have pros and cons, but we’ve found that we can overcome the challenges of collaboration to take full advantage of the rewards.

Pros of coding alone

Before CivilCode, Nicholas and I liked working as freelancers, so we understand why some developers prefer working in isolation:

• You get to do everything your own way, using your preferred process and methodology.
• Working alone feels right to coders who are introverted and accustomed to learning and working alone.
• It can seem like you’re working faster, since you don’t have to explain anything or wait for reviews. We consider this a short-sighted gain that limits quality and learning opportunities.

Cons of coding alone

Although we were satisfied working alone at first, eventually the negatives became too strong to ignore:

• Being the only one working on a project can be stressful. It can feel like you’ve been thrown in a corner and tasked with making something work. You can’t get sick or take time off when you have a deadline.
• You’re the only contact person and can feel like you’re always on call.
• As a solo coder, you’ll likely be placed in a silo, which can be limiting — you’re good for X type of project, but the really interesting Y and Z projects require a more versatile team.
• Your code isn’t subject to peer review. While this might seem like a pro to some, it’s a con because peer review ensures higher quality and reduces the stress level of having the burden of producing error-free code on one person.

Pros of developing software collaboratively

A collaborative team works with a shared opinion of how they code, their process, how they use tools, and how they approach design.

Simply putting a group of former freelancers together and telling them to work collaboratively isn’t magic that instantly erases all the cons of working in isolation. We’ve purposefully refined our collaborative process to meet the needs of both our team and our clients. The environment we’ve created optimizes the benefits of collaboration:

• Working with a team gives us more collective expertise so we can take on bigger projects, and solve more complex business problems.
• A collaborative environment is a continuous learning process that encourages growth and gives everyone the opportunity to develop professionally and improve their craft.
• We use a pair programming system, so there’s never one person with sole knowledge of a project, which greatly reduces stress and accommodates illness and time off.
• Peer review produces higher quality code. Knowing that others will be reviewing and collaborating with you enforces discipline in structure and writing code that colleagues can logically understand.
• Having a curated set of tools that the team uses for the type of projects we work on speeds development time and reduces stress.

Cons of developing software collaboratively

Even though we strongly prefer working collaboratively, we understand why some coders are hesitant about working this way. We take measures to minimize the cons to provide the best working environment:

• Since we already have a curated set of tools, processes, etc. our preferences may conflict with a new team member’s opinion about how we should be working.
  How we minimize this con: New developers are welcome to contribute their opinions, and we will take new ideas into consideration, but it’s important to understand that the team isn’t going to completely change its approach each time a new idea is presented.
• Peer programming can be challenging for someone who hasn’t worked that way before.
  How we minimize this con: We encourage open communication about different people’s thinking styles. Some people need more time alone to think through a problem, so we build this in to the pair programming process.

Since our collaborative process is one that we uniquely created for CivilCode, there will always be an adjustment period for a new developer. To ensure that the process continues to work well and evolve, we take time every Friday to work on pain points in projects and our process, so everyone has the opportunity to voice concerns. This structured approach to requesting and evaluating feedback has proven to be extremely helpful to all team members.

Have any questions about our collaborative process or any aspect of our business? Contact us.

Rewards and challenges of collaborative software development was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Embarking on a custom software development project is essentially crossing into uncharted territory. Although we most likely won’t face dragons, there are risks. But, it’s by taking risks that you reap rewards. The creation of new software with custom functionality gives you a powerful tool that’s unique to your business. Building that tool requires trusting in a non-linear process.

Software development is called an empirical process because the requirements are expected to evolve; the process can’t be defined from the start with a set series of steps. To people outside the software development world, this flexible process is often a surprise. Within the industry, Agile software development and the Agile manifesto are well known. I like this quote from Estimation is Evil by Ron Jeffries, Signatory of the Manifesto for Agile Software Development:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”

Of course, we start with discovery and a plan, but it’s more useful to think of the plan as the definition of the project’s value rather than a destination. For deliverables, we use the adaptive approach favoured by Agile methodology. What that means is we develop and deliver features incrementally. Regular delivery of working software gives our clients the opportunity to see value early. Incremental delivery also builds confidence in the team and our process, and gives clients the opportunity to provide feedback right away.

Collaboration and communication are essential for product success

As we embark on the process of creating something unique, issues, questions, and problems will arise. These challenges are an expected part of the process, and they serve as opportunities to recalibrate the project’s value. Throughout the project, our team collaborates with the client team to find the simplest, best solutions to every problem. In some cases, a problem may be a rare occurrence that’s best solved by allowing manual intervention rather than increasing the scope of the project and expending more resources.

Project value must take priority

To minimize problems, it’s essential to keep functionality and value as priorities. Two factors can threaten functionality and value are feature requests with low return on investment, and schedule constraints. It’s normal for some additional feature requests to arise after the project is underway, but to maintain project integrity, those new features must be evaluated against the overall goals for the project. New features may be great ideas, but can also cause endless rework and compromise the forward momentum of the project.

Meeting scheduled milestones is important to keep the project moving in the right direction. However, there can be instances where sticking to the immediate schedule could have a high cost in the long term. If implementing the best solution to an issue requires some schedule flexibility, then a difficult decision must be made. Sticking to the schedule purely on principle doesn’t support the objective of creating a unique product with high value.

While in a sense a product is the result of software development, the process is closer to research than manufacturing. New information will be revealed as the process moves along. Each new piece of information must be evaluated and incorporated to best serve the overall project. If the schedule takes priority over project value, essential information may be discarded to the detriment of the project’s overall value.

The reason for examining these misunderstandings isn’t to cause hesitation in starting a project. My intention is to offer some insight about why the process isn’t straightforward and why we want to keep it that way. Ongoing discovery throughout the process allows the end results to be innovative and transformative.

Have questions about our software development process? Ask about our agile approach or any aspect of our business.

Why software development isn’t a linear process was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Context switching is a computing term that describes how an operating system stores the state of One process (A) before starting another process (B). Before resuming process A, the state of process B must be stored. We use the same term to describe how humans switch from one task to another. Although context switching involves working on different processes or projects, it is not the same as multitasking.

Multitasking is doing two or more things at the same time; for example, texting while driving. With multitasking, one or both tasks suffer from decreased attention. Context switching is stopping one task before starting another, like alternately texting and driving. Each time you want to read or send a text message, you have to find a safe place to pull off the road, pull over, put your car in park, pick up your phone and then text. To resume driving you have to move the phone aside, put the car in gear, and then get back on the road and up to speed.

Hidden costs of context switching

Developing code carries an extremely high cost of context switching. The most productive way for our developers to work is to focus on one project each week. In our experience, we’ve seen that trying to devote attention to more than one project in the same week results in multiple inefficiencies. The time spent getting back up to speed on a different project is the first inefficiency; however, it’s not the biggest offender. The mental cost of context switching is where the cost of context switching skyrockets.

Finding elegant solutions to problems is everyone’s goal on a project. When working on complex coding problems, creative problem solving is required to come up with the best solutions. Being immersed in a project, considering problems from different angles, and allowing the time and space needed to devise solutions is how brilliant ideas are generated.

Being asked to stop work on one project and pick up another from one day to the next; or worse, in the same day, is unproductive and demotivating to our developers. They lose momentum they’ve built getting up to speed in the original project and may lose a train of thinking that was leading to an innovative idea. Switching from project to project requires a great deal of mental energy and can quickly lead to burnout.

Using time blocks to prevent context switching and promote saw sharpening

As a company, we work on multiple projects at the same time; however, we ensure that individual developers are protected against context switching. To prevent context switching, we make sure that each developer is focused on one project per week. Monday to Thursday is one block of developer time, and that block is 100% devoted to the same project. Our no context switching policy is in place to protect both our resources and our clients against the detrimental effects of context switching.

If a pain point arises during the week, it can be solved on Friday without compromising the project schedule. For example, if we discover an inconsistent coding practice in the application we’re building, we would take the time on Friday to standardize everything to ensure consistency. Fridays also have time reserved for “saw sharpening” — a habit recommended by productivity expert Dr. Stephen R. Covey. On Fridays, people can take the time to learn, improve, and expand their skills. Continuous improvement keeps our team extremely sharp and efficient.

Why our clients prefer time blocks

Clients benefit from our time block system several ways. The first benefit is quality. Clients reap the rewards of having “sharp” development resources focused on only their project during each time block. Another benefit is billing regularity. Clients have a predictable amount of billing each month, with no spikes or dips in hours.

Minimizing context switching and working in time blocks has proven to be an effective way to keep our team operating at a high level. Time block scheduling is also a cost-effective strategy for our clients.

Want to know more about our time block system? Ask about our process or any aspect of our business.

Minimizing the cost of context switching was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

User satisfaction will make or break the success of software implementation. It seems obvious, but big and small implementations can fail due to failure to meet user requirements. Paying attention to what users need during the discovery process is a good start, but how do you ensure that those requirements aren’t compromised as development progresses?

At CivilCode, we use Test-Driven Development as one strategy to make sure that we deliver highly functional, user-focused solutions.

What is Test-Driven Development?

When we do Test-Driven Development, we start with the requirements. Every feature or function is converted into a test case, meaning we write down what the user would do, and what results are expected. At first, of course every test will fail. Code is only added if it is needed to pass a test. No extraneous code is allowed to creep in.

It’s important to note that before we start this process, we’ve already invested a significant amount of time and design work in modeling and identifying the necessary requirements.

Shouldn’t testing be done later?

By writing test cases first, we ensure that developers are following requirements closely. Creating good test cases means that they might have to go back to the information gathered in the discovery process to understand exactly what the users need, and if any exceptions or special exceptions need to be accommodated.

By testing every incremental step as we go, we also have peace of mind that if something developed later breaks earlier work, the automated tests we’ve created will fail. There won’t be a long delay between development and a big testing phase, where any issues could require a lot of backtracking and unraveling.

We do use other testing techniques at different stages in addition to the test cases created during development.

What if you do have to go back and make changes?

As development progresses, sometimes we have to do refactoring — that’s changing how we implement a feature. We might have to think of a better structure than the one originally created, for example.

What’s good about Test-Driven Development is it provides a fast way to make sure that any refactoring changes we make don’t break something we did earlier. If a previous test fails after we make structural changes then we know we have to stop and fix it or go back and undo the changes and re-think our approach. The test cases we’ve built will catch problems right away.

Isn’t it slower to be writing test cases as you go?

In our experience, it’s the contrary. By having test cases always done, we can maintain our development velocity as the program gets bigger and more complex. Without a verification test suite already created, adding a new feature would be much slower due to the testing required.

Since we also use pair programming, writing test cases and code simultaneously is not as slow as it might seem if it were one person trying to do both alone.

An important advantage of test-driven development we like is that since code is only written to make a test pass, every line of code is tested. Nothing falls through the cracks, which makes for a cleaner, more robust system overall.

Have questions about how we test software as we develop? Ask us about Test-Driven Design or any aspect of our process.

How Test-Driven Development keeps software aligned to system requirements was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most people picture software developers hunched over a keyboard, clicking away in silence, alone. A problem with that scenario is that one person is intimately familiar with the code and no one else knows what that person did without ongoing knowledge transfer.

If you visited our offices, you would see a different setup because we program in pairs, with a team of two at a workstation. The pair share the controls like a pilot and co-pilot. Of course, only one can drive at a time, but the 2nd person is an invaluable part of the team.

Pair programming improves decision-making

One of the benefits of pair programming is that for complex code requiring many decisions, those decisions can be tested along the way. If one person were programming alone and had a question, they may try to answer it themselves and possibly not find the best answer or go ask a co-worker which requires bringing that co-worker up to speed and interrupting the other work the co-worker was doing.

By building code together, the best way to design code is discussed and validated as its written. The pair takes turns being the pilot or driver and co-pilot or navigator. The navigator is also writing test cases and tracking any other ideas that come up or issues that will need to be addressed. The driver focuses on writing clean code.

Pair programming forces discipline and boosts creativity

Working in pairs imposes more discipline than working alone. Proper procedure and best practices must be adhered to or both people can’t follow what’s happening.

However, even though it’s disciplined, pair programming isn’t rigid; in fact, it encourages brainstorming. The pair approach works particularly well for parts of the development process that allow some creative license and must be clear to many people such as defining names and concepts.

Pair programming continuously transfers knowledge

Another benefit is that pair programming ensures instantaneous knowledge transfer so that more than one person is extremely familiar with the code. If one person is on vacation or out sick, progress can continue with the other person in the pair. The same is true for any fixes or maintenance later. Availability to work on that project isn’t restricted to one person who knows the code or dependent on knowledge transfer. We double our resources with built-in knowledge sharing. By developing together like a pilot and co-pilot, both developers keep the code on course and either one can take over in case of emergency.

Pair programming creates validated code with fewer defects

Not surprisingly, code written in pairs results in fewer defects and many issues being ironed out right away. Having a second pair of eyes instantly screening every line means that the code has already undergone a thorough quality check before it’s even tested. Minimizing rework and bug fixes later in the process is a huge time savings.

Pair programming requires the right team members

Pair programming does not work well in all environments. In places that rely on a few superstar geniuses to do all the heavy lifting, pairing them with junior programmers wouldn’t work well. Certain personality types do not function well working in pairs.

However, with the high experience and expertise level of the people on our team, our culture, and the process we use, we have found that pair programming works exceptionally well to allow us to deliver quality code quickly and efficiently.

Want to know more about our software development process? Ask us any questions you have about the steps we follow and our approach.

How we use pair programming to develop high quality software was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Although it can at times be irritating when multiple apps are updating on your smartphone, those updates are essential to keep everything running as smoothly as possible. Similarly, custom business software also requires updating and maintenance to keep it functioning well. This article gives a brief overview of some of the main reasons why preventing software “erosion” is so important.

Reacting to the constantly changing software and hardware environment

Why does software that was working one day suddenly stop working the next day, even if nothing changed? Something most likely did change. The entire environment is constantly changing. Operating systems change, hardware changes, standards change… it’s like waves constantly hitting the software. A well-designed system can withstand some changes, but without fortification or updates, it will start to erode.

Ensuring compatibility

In addition to the changes mentioned above, Application Programming Interfaces (APIs) for 3rd party programs used by the software such as payment systems and maps are frequently updated to accommodate new functionality and to address security concerns. These changes are not originated by the software developer, but by the other programs or systems and the software will not work as well without being revised to use the new APIs.

Managing dependencies

One of the trickier aspects of software maintenance is dependencies on software components such as libraries. Libraries are modular and meant to be shared by different programs, which is extremely efficient, but also where problems can creep in. If one program requires a new version of the library, upgrading may break other programs still dependent on the previous version. Small breaks can go undetected like tiny rust spots that eventually spread into massive corrosion. Staying on top of dependencies is essential to prevent bigger problems.

Minimizing security risk

An advantage of custom software is that it can be less attractive to hackers to try to compromise since it’s not used as widely as commercial software. However, exploitable holes do appear, sometimes in 3rd party programs, so implementing the latest security updates is essential for protection. The investment in updates offers an excellent return when compared to the potential losses that can occur when business-critical systems are infected with malware.

Maintaining performance

Poorly maintained software can become bloated, with workarounds and unnecessary code slowing the system down. If part of the program is being used beyond the original intended capacity, there is often a more efficient way to handle the new requirements. Implementing that new code will save time and prevent breakdowns.

Erosion, corrosion, is there any way around it?

As with mechanical objects, software requires maintenance and upkeep. Ignoring little “creaks” may be okay in the short run, but isn’t a good long-term strategy for keeping an important tool in working order. It’s much easier to maintain software when it simply needs to be updated from version 3 to version 4 rather than waiting until it needs a massive update to version 8.

Have questions about how we prevent software erosion? We’re happy to explain requirements in more detail for specific applications.

Why ongoing maintenance is needed to prevent software erosion was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the software development world, a product owner is someone who takes responsibility for the success of a project from the customer’s viewpoint. An effective product owner will be able to execute the following responsibilities:

1. Understand what the business is trying to accomplish

Knowing what success looks like from the customer’s viewpoint is the critical part of the product ownership role. Some teams will use a product owner provided by the developer, but to ensure that the customer viewpoint is always prioritized, it makes good sense to have the product owner be provided by the customer.

2. Communicate effectively

The key function of a product owner is communication to all team members about all aspects of the project, including priorities, deliverables, schedules, scope creep, budget, and risks. The product owner is responsible for keeping the customer stakeholders informed about progress.

When a customer stakeholder wants to know what’s happening in the development process and how the solution will work, the product owner should have the answers. A product owner who is an effective communicator will provide an explanation at the appropriate level of technical detail for whomever is asking. A product owner who understands the needs of different stakeholders will know that the chief financial officer is looking for different information than the customer service manager.

3. Make the right decisions quickly

To keep the project moving, the product owner must be able to make the right decisions quickly. With a solid understanding of what the customer needs, making decisions should come easily to the right product owner. When the development team needs to know how to handle a request that could cause a delay, the product owner should be able to evaluate the situation, have the authority to make a decision, and provide direction.

4. Leave the “how” to the technical team

While an effective product owner must have a good technical understanding of what the development team is doing, it isn’t the product owner’s role to determine how the functionality will be implemented. Of course, the product owner will have a lot of input, but that input needs to be about what the solution needs to do for whom, and why. How it’s best accomplished technically is up to the developers.

5. Have the trust and support of upper management

Without buy-in from upper management, the project most likely won’t succeed. A product owner who understands the business, can communicate effectively, and can make the right decisions quickly still needs management support.

Understanding the culture of the business is an invaluable asset for the product owner. Is the company risk-averse? Does management need to know the minute the schedule slips even slightly, or do they only want to be informed of major issues? Providing the level of communication needed prevents unpleasant surprises and unnecessary aggravation.

What does success look like from the customer’s viewpoint? That question will be on the product owner’s mind at every step in the process. By repeatedly asking the question and keeping the project on track, a product owner will truly own a large portion of the credit for the success of the project.

5 ways to be a powerhouse product owner was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

When evaluating whether or not to add in-house resources to develop custom software, there are several important questions to ask.

Where is the complexity?

If the software being developed uses proprietary algorithms or requires an intimate in-depth knowledge of the business, it could make more sense to use in-house resources. Which would take longer, training in-house resources to master the necessary development skills or explaining the business process to outside developers?

Who has the necessary skills?

Properly executing a moderately complex software development project will require expertise in a variety of skills such as project management, database architecture, and coding. It’s rare to find people who can do everything well. Software developers are in demand, and experts are often found working for consulting firms that encourage and accommodate specialization.

When does the project need to start and finish?

Building a cohesive team takes time. Including a hiring process and ramp-up time for in-house developers can slow the start of a project considerably. External developers already have teams and processes in place to start projects quickly. They can also expand and shrink teams as a project moves through different stages.

What are the business goals?

Is investing in a software development team part of the core business strategy? Adding employees requires overhead, space, and benefits, and comes with the responsibility of maintaining a higher head count. Outsourced projects can be done in phases and put on hold or sped up when necessary.

How can concerns be addressed?

Some common fears about outsourcing include lack of communication and loss of control. Regular, transparent communication is essential. A reputable third-party developer will have solid project management practices in place and should excel at client communication. Consultants that go dark and lack communication skills won’t stay in business long. When checking references for a potential development company to use, ask about the level and frequency of communication provided. Ask, “Were you satisfied with how the company communicated progress?”

Regarding control, there is no comparison to being able to direct what an employee does on a day-to-day basis; however, a third-party development team is heavily invested in the overall success of the project. Accommodating shifting priorities should be something they’re equipped to handle. A good question to ask when evaluating potential partners is, “How do you handle a change in priorities?” They should have a good answer that demonstrates experience handling exactly this situation.

Existing in-house IT resources should be involved in the decision about whether or not to outsource. Their input will be invaluable since they have both domain knowledge and an understanding of the technical requirements. In many cases, outsourcing makes good business sense. A successful project will have both one or more in-house champions as well as a trusted outside development partner that becomes an extension of the existing team.

Should you outsource custom software development? was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

When demand increases and is about to cross a significant threshold, it’s an opportunity to show what a company is made of and how solid its foundation is. Will existing internal processes be able to handle the increased pressure and volume? A tailored software solution can help ease the transition when scaling rapidly by offering many advantages.

Automating manual processes

The easy win for a custom software solution is replacing manual processes. Anything that can be automated will save time incrementally as more people use the system. Triggering notifications is one common process that can save the time that would otherwise be required to send individual messages. Showing time saved for existing processes can provide bottom-line, easy-to understand numbers that get projects approved from finance and accounting, but the bigger wins for businesses often exist beyond basic automation.

Streamlining procedures

An extremely valuable benefit of developing custom software happens before even one line of code is written. In the discovery phase, the essential processes used by the business must be defined and deemed necessary to support the company’s objectives. This step can be revelatory as the need for custom software often occurs at a pivotal point in a company’s growth. By clearly defining objectives and priorities before a rapid growth phase, everyone who interacts with the company as it grows will have a clear understanding of what the company does.

Each person using the custom software can do exactly what’s needed without workarounds. People interacting with the company will also have a cohesive experience of not waiting for information to be retrieved slowly from an outdated legacy system.

Improving quality

An important side benefit of streamlined procedures is improving data quality. Having reliable, high quality data in your system can prevent costly errors. A well-designed system can easily handle increasing volume and produce results that don’t require manual intervention or double-checking.

Allowing flexibility

Since you own your custom software, if you need something changed you can have it done. This isn’t possible with an off-the shelf solution. You can ask, but your innovative idea may not align with what the majority of users are doing, and your essential new feature won’t be implemented. Or maybe you don’t want to give your great idea away to someone else to sell it with their product, you want to keep it for your use only. Your custom software evolves as your company grows and includes the new features you prioritize as your capabilities expand.

Broadening reach

Custom software solutions in 2018 have little to no resemblance to pre-cloud proprietary systems developed in-house. The software development tools and cloud storage solutions available now make online, collaborative systems a smart choice for many businesses.

Online accessibility allows remote access for people travelling and can often accommodate different devices. If salespeople need access using smartphones and tablets, it can be done. Top talent often expects to have remote access and to be able to bring their own devices. A constrained, local-access only system can be a hindrance to growth.

A well-designed custom software solution that supports key business functions allows each user to work at high levels of efficiency. Having a reliable, efficient system in place is an excellent strategy to prepare for rapid growth.

Scale your business with custom software was originally published in The CivilCode Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.