In 2017, as founders of a newly formed company, we made the strategic decision to move to Birmingham, AL. There are quite a few reasons why Sigao moved to Birmingham, but one primary reason stood out above the rest. A seed planted in the wrong soil isn’t going to grow, no matter how well you take care of it. For Sigao to grow, we needed a place where the community’s culture fit with the culture we wanted to build. In this blog post, we’ll take a look at the reasons behind the move, how the city has positively affected the company, and what the future holds for Sigao in Birmingham.
We moved for the startup scene
When Sigao made the move to Birmingham we weren’t much of a company. Just four people in basement with a few minor contracts to keep us going. In fact, on paper it probably wasn’t even the right move. When we changed locations we increased our cost of living, increased our competition, and severed many of the connections we had in our previous city. However, we knew that something was happening in the Birmingham tech scene, and we knew we wanted to be a part of it.
What we found surprised us.
We quickly discovered a small yet passionate (and perhaps a bit disjointed) tech community. One that instantly opened its arms to outsiders. From the moment we arrived, we received support and encouragement from everyone we met. People we hardly knew would go out of their way to make high value introductions. It seemed their reasoning was simple: we’re a Birmingham business. That’s just what you do.
Another thing that stood out to us was the lack of harsh competition. Sigao never experienced the cutthroat, calculating environment that so many startups deal with. Instead, we saw companies passing work opportunities to other members of the community. We met business leaders promoting partnerships and collaboration over cold business strategy. Most importantly, we met a group of people stubborn enough to look at huge problems and think “I can fix that”.
We moved for the food
We have always believed that part of being successful at work is being happy outside of work. And to us, few things contribute to happiness and wellbeing like good cuisine.
Food provides a lot of things that other forms of entertainment do not. Its an opportunity to connect to people around you. A chance to expand your tastes. Its even a starting point for learning about new cultures and customs that you otherwise would not have experienced. Eating is a universal activity that brings people together and broadens their horizons.
In Birmingham, we found a vibrant food scene that still continues to surprise us years later. Fine restaurants serving dishes that rival those in major cities. Breweries with food so good they win awards. Hole in the wall shops serving the same meals for over 100 years. The city may be small, but it plays in the big leagues. Even in a post-COVID era, with our team’s rarely ending up in one place, we still make it a tradition to order the same local meals every time we’re together.
Employee wellbeing and happiness is a top priority for Sigao, and being in an area with a rich food culture has helped fulfill that mission. It may seem like a minor thing, but good food is the focal point for many things that aid wellbeing. Its allowed us to explore the city, support local businesses, meet new people, and form bonds with each other and the community.
We moved for the people
Before making the call to move, we had only a basic understanding of Birmingham’s culture. We knew about its history (both recent and distant), and knew that people were working hard to push the city’s image into the future. But, beyond that, we really didn’t didn’t have a strong understanding of the community we were about to join.
Still, we were drawn to the city’s spirit of change and forward-thinking attitude.
Having access to a community like that is not a trivial thing. Starting a business is a difficult, lonely endeavor with a high failure rate. Often the biggest challenge is simply maintaining optimism in the face of hopelessness. It makes a huge difference to know that the people around you truly believe in the future of your city.
In a way, the city its self is a startup, which is why it fits us so well.
Its a group of people using imperfect tools to achieve a common goal in the face of long odds and deep setbacks. It doesn’t matter if you’re talking to a tech entrepreneur, a lawyer, a bartender, etc. People here have a shared connection and sense of purpose when discussing what the city could be. Its been inspiring and energizing to be a part of that, and we attribute a lot of our success to the people fighting to make the city better.
Environment matters
If there’s one thing we’ve learned on this journey, its that your environment is important. No matter how talented you are, and no matter how hard you work, you’ll always need support and collaboration from the people around you.
As Sigao enters its 7th year in business, we’re transitioning to a stage where we can be on the other side of that support. I recently witnessed someone refer to Sigao as an “established” Birmingham tech company, and I’ll admit it kind of floored me. Its difficult to think of yourself as “established” when the memories of working out of a cramped living room are still fresh on your mind.
Yet, after some reflection, I realized they were right. At some point in the last few years we stopped being the newcomers searching for a place to plant our flag, and became part of the community that drew us here.
That means we now have an obligation to those that come after us. Whatever the future holds for Sigao, one thing is clear. We’ll be here, along side the rest of the community, offering support and encouragement to anyone else who decides to join us. That’s just what you do.
The decision to buy an off-the-shelf solution or build a custom solution is one that every business must make. It’s a difficult choice, as there are many pros and cons of building custom software. To help you make the best decision for your business, we’ll a look at both software acquisition approaches.
Purchasing Off-The-Shelf Software
When it comes to purchasing software, there are several advantages to consider. First and foremost, buying commercial off-the-shelf (COTS) software is upfront cost savings – both in terms of time and money. When you purchase a pre-built software solution, it’s often much faster (and cheaper) than attempting to build something from scratch.
Additionally, a large user base means that the COTS has likely been tested by thousands of people. This limits the possibility of bugs or glitches before you incorporate the software into your workflow. This means less risk on your part, and fewer headaches down the road due to compatibility issues or other problems with an untested system.
Of course, there are also downsides: namely, lack of customization options and potential vendor lock-in issues. These could be especially problematic if they decide to stop supporting their product, or get acquired by another company. Additionally, since pre-made solutions need to cater for a wide range of customers they may not always provide intuitive user interfaces or enable personalization options. This can leave users confused, or force business to change their processes to match the software.
Lastly, if the “out-of-the box” solution doesn’t quite meet all your needs, it tends to be difficult – or impossible – for it do so without significant customization. Theses customizations can be expensive and unstable, negating the cost savings from buying pre-made solutions.
Building Custom Software
One major advantage associated with building custom software is having total control over the product. Businesses can ensure that the system meets all their needs, without the limitations of “off the shelf” products. This allows for greater internal adoption and implementation as it lets the software conform to the business, rather than the business conforming to the software.
Additionally, custom software allows for greater flexibility and scalability. Since the code for these applications is proprietary, companies may find themselves with a competitive advantage against those using shelf systems. Custom software allows companies to respond to user feedback quickly by developing better tailored versions to improve user experience.
Lastly, as businesses grow the shortcomings of a one-size-fits-all approach are magnified. Inefficient processes amount to hundreds of lost hours throughout the year. All while recurring expenses rise due to increased users or added features. Since businesses are stuck “renting” technology, they are unable to reap the benefits of owning their technology. In many cases, medium-size businesses are able to see positive ROI in as little as three years by developing their own custom software solutions.
Conclusion
The needs of every business are different. Understanding the pros and cons of each software solution alongside the specific profile of your business is critical to making the right decision. At Sigao, we invite you to do the research with us. We’re happy to help you assess the software needs for your company.
As veterans of the custom software industry, our team has encountered countless questions about the creation of custom software solutions. However, few questions are as difficult to answer as the very first one.
“Do I need custom software?”
Software is wildly complex, both from an engineering perspective, as well as a business value perspective. Today’s applications can touch so many aspects of an organization that accurately gauging the investment can be a challenge. On top of that, no two engineering firms are the same. Some may provide ultra-specialized engineering services for one aspect of the project, while others may provide broader, more consultative services that cover more of the project scope.
The natural reaction to attempting to process too many choices is to intuit the answer. To try to “feel” that the variables are pointing one direction or another. This is dangerous as it leads to Confirmation Bias, giving you the impression that all the information you discover appears to point in the direction you want it to point.
In this article, we’ll discuss some tangible aspects to consider that will provide a framework for making the decision. Keep in mind, this is too complex of a subject to cover in one article. Our hope is that this information provides valuable measures that help you feel more confident about the process.
Analyze the “Why” Behind Your Custom Software
Every software project begins with the same thing: a problem.
Unfortunately, people are good at solving problems.
Take a minute to think through the last problem you solved. It can be anything. Maybe your phone wasn’t working, or your car was making a weird noise. Whatever it was, think about how you instinctually responded when you discovered the issue. I’m willing to bet that the first thing you did was immediately start trying to figure out the underlying cause.
Did you mull it over in your head, vetoing unlikely scenarios and coming up with new explanations. Maybe you googled the issues, trying to find others who have solved this problem. Whatever path you took, its very likely that you got sucked into finding a solution without paying much attention to the problem its self.
People are hardwired to solve problems. We’re good at it, and by and large, we enjoy it. Unfortunately, that aptitude leads us to dive into solutions, while giving the problem only a cursory glance. Maybe the cost to fix the problem isn’t worth it? Maybe the problem opens up doors to fix other areas? What if there’s an ugly, but effective solution that’s far easier than the obvious solutions?
For small, every day problems, the downside of ignoring this kind of deep analysis is minor. A few hours here, a few dollars there, no big deal. Yet, software projects are huge investments, with vast consequences. Most problems are solvable, but the real question is should you solve them?
Know your problem, ignore the solution
Nothing related to a solution matters at this point. Not the price of the solution, not the technology (or lack there of) of the solution, only the problem. Our team consistently encounters people who “know” what software frameworks we need to use to solve the problem. Yet these people often are not able to describe the problem in detail. They’ve allowed themselves to dive into the solution without truly knowing the value of the problem, which makes the decision little more than a gamble. Before moving forward, these are some of questions you should be exploring:
How many people does this problem effect?
How much time/money do you lose from these effects?
Are there 2nd or 3rd parties affected by the primary party’s issues? How much time/money do you lose there as well?
Are there multiple facets to this problem? If so, which is the most valuable to solve?
Are there adjacent issues that you can address in tandem with the primary issues?
The more you can understand the problem, the more you can assist other’s to build a good solution.
Why knowing your problem is so critical
The less you know about the value of the problem, the more you end up guessing about the value of the solution.
At its core, a software project is a continuous cost/benefit problem. You expend X amount of effort for Y amount of return. If done correctly, Y ends up significantly larger than X. Because of this, one of the largest factors in a successful project is how well those involved understand the problem.
The less you know about the value of the problem, the more you end up guessing about the value of the solution. Each decision becomes a gamble, rather than a calculated risk. And you will be making decisions if you continue down this path. As the owner of a project you will face a constant stream of decisions related to the value of your solutions.
Do you sign off on using a 3rd party tool that costs $100/month, but will end up saving 2 months of project work? What if that feature is only solving a problem that costs a handful employees 10 minutes per day? Engineering groups can provide information, and some (Sigao being one of them) can even assist in analyzing those choices. But, the final decision must come from those who understand the problem the best.
The next reason is perhaps the most important. It’s what elevates project outcomes to to their maximum potential:
Extreme understanding of the value of the problem allows for the most creative solutions.
Knowing your problem fosters innovation
Knowing what is and isn’t important allows the engineering team to propose creative solutions. My favorite example of this is what happens in some of our initial discovery meetings. People will often approach us to build a project having already landed on a desired solution. They’ve spent weeks or months imagining a complex solution that addresses ALL their problems, without knowing the value of those problems individually.
This is a common scenario, which we address with an array of discovery questions. We try our best to help our customers refined down the most valuable aspects of their solution. During that process we occasionally encounter situations where the value is so concentrated on one aspect of the problem, it allows us to bypass the majority of their requirements. If only a handful of requirements are worth the investment, why bother with the others?
The results are often eye opening. Given a narrowed scope, the team is free to adopt a more Rapid Testing mindset. We’re able to suggest ideas that may not even involve writing code, but will solve the problem quickly. This allows the customer to assess portions of the solution individually before committing to a large scale system. Sure, these solutions are typically “quick and dirty”, but the amount of value they provide negates the downsides.
Its not uncommon for our customers begin a meeting envisioning a $50k+ system , only to leave the meeting with a way to solve most of their problems for free. All because they were able to recognize the most valuable problems to solve.
That’s the power of understanding your problem. When you know what’s most valuable, you gain the ability to make more intelligent decisions about where you invest your time and money.
Long Term “Why” Behind Your Custom System
One of the biggest issues we struggle with in the software industry is conveying the benefits of a custom solution. It’s difficult for people to get past the initial shock of the price, and a lot of that is because they haven’t truly considered the problem their solving.
Custom software systems are like sports cars. Expensive to build, expensive to maintain, but capable of doing amazing things. Part of knowing your problem is knowing how much the value of the solution builds up over time. If you a development team quotes you $300k for the solution, is that bad? Maybe. What if it will save you $70k per year and will turn a profit in 3 years? What if you’re currently paying $40k/year in subscription costs which will disappear after the project?
Think back to the “adjacent issues” you explored. Could owning your own data provide more opportunities for value over time? Could you later pivot your solution into a product that you then sell to other companies similar to your own?
Time is a powerful factor when considering the problems you’re solving. Solutions typically provide value for long after the initial project cost.
How Much to Invest in Custom Software
By now, lets assume you have your problem mapped out. You know how many people it affects, how much they lose, and how much money you’re losing by not addressing the issue. The next question is, can you feasibly afford the solution?
Custom software is expensive, and there’s not much you can do about it. Even if you are absolutely convinced of the value of your project, there will still be significant investment to get to the end goal. There’s no cutting corners if you expect good project outcomes, which is why its so important to know what you stand to gain. We plan to cover this topic in more detail in later articles, but for now we’ve provided a reference table for you to plan against.
Keep in mind, many factors affect these prices. Some seemingly difficult features are solvable in days, while others that appear simple can take weeks or month to accomplish.
Reference Table For Estimating Project Costs
Project Type
Price Range
Description
Simple Marketing Website (Contractor)
$1-5k
A simple marketing website meant to display information, built by an independent contractor. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms.
Simple Marketing Website (marketing firm)
$5-30k
A simple marketing website meant to display information, built by an experienced marketing firm. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms. Typically would include more robust designs/mockups, more help with hosting, as well as maintenance and trouble shooting.
Proof of Concept Web/Mobile App
$30-70k
Web or mobile app, built by an engineering firm, designed to show that the intended functionality is possible. May not be complete, or visually appealing. May not scalable. These are typically used to attract investors.
Mid size Web App
$70-300k
Web or mobile app, built by an engineering firm, designed to accomplish a business function. These may absorb several business areas, allowing the company to remove multiple paid products from their workflow. This price range may also be applicable beta product launches, depending on the complexity of the product.
Enterprise Web App
$300-1,000k
These are large, overarching systems that touch multiple aspects of a business and hundreds of users. These systems have multiple integrations with other systems, multiple roles throughout the organization, and strict uptime requirements. For new products, this range would likely cover several major versions of an early stage product. If promoted properly, a new product with this much investment should typically be generating revenue and attracting large investment firms.
Follow Through with your Custom Software Project
You know your problem, and you have an idea of what its going to cost. Now what?
If you have the corporate backing or funding to move forward, the next step is to start evaluating vendors. Spend time finding a group that’s trustworthy and has a proven track record. Make sure their clients willing to vouch for their capabilities. Find out if they hide the development team, or let you interactwith the people building your solution. Finally, make sure their contracts are set up to share risk on both sides of the project, rather than pinning it all on you.
Most of all, find someone you get along with. There WILL be stress, there WILL be miscommunication. The best way to navigate that is by working with someone you trust.
Final Thoughts
Assessing whether you need custom software is a difficult task, but it doesn’t have to be guesswork. Sure, you won’t always find perfect ways to assign value to the problems you’re trying to solve. You won’t always have all the information you need to make a perfect decision. However, with a little effort, even the most complex problems can be evaluated and broken down in a way that empowers you to make better decisions.
As providers of software development services, we encounter clients from a wide variety of backgrounds and industries. All companies, from startups to mega corporations, have business problems that can be solved with technology solutions. However, software development is a wildly complex skillset that is often made less comprehensible by ever-evolving jargon and practitioners who are only familiar with talking amongst other practitioners. This leads to a massive knowledge imbalance between buyers and sellers, which in turn opens the door for unskilled teams to take advantage of unsuspecting buyers.
Over the years we’ve heard countless stories of buyers having bad experiences with their software projects (in fact, we’ve helped fix a couple of those projects!). Whether its buying software that isn’t needed, entering into unfavorable contracts, or simply not being aware of the expenses involved with a project until its too late, the buying process is filled with potential pitfalls that can affect the overall success of the project.
Because of this, we’ve decided to provide an educational guide for buyers. This should not be considered a comprehensive checklist, but instead a starting point for further research. Our goal is to help prepare you for what to expect, what to ask, and what you should know to avoid making costly mistakes.
What should you think about before starting the process?
Many potential buyers have not fully considered what building and owning a software system means. This is a big undertaking with big ramifications for your business. Take a few minutes to consider the following pitfalls and misconceptions that new buyers deal with.
Software is expensive
This is the number one thing that most people are surprised by when they first start looking into a software project. The skills required to properly build a software application take many years of constant training and dedication to refine. What further complicates this issue is the relatively low barrier to entry. Virtually anyone can take a few free courses and call themselves a developer, and many people do. As the market saturates with new, inexperienced developers, it leads buyers to assume that it’s an easy/common skill set that shouldn’t cost much.
Worse yet, lower skill developers typically focus on skills that produce visually appealing, user facing code, while not training on how to scale large applications. This means that buyers often don’t realize their software is broken until they attempt to onboard users and their money is already gone.
It can not be overstated how often we encounter buyers with broken code bases and empty budgets looking for a quick fix to system that is beyond saving.
While the lure of cheap developers is a powerful one, keep in mind that the vast majority of projects made by low skilled developers need to be scrapped. While prices can vary wildly based on geographic location, a typical US based proof of concept project will run anywhere from $50,000-100,000. Hourly rates for talented on shore development firms will likely be anywhere from $110-185/hr, and potentially higher for teams that provide DevOps engineers and have enterprise software experience. Talented developers are worth their weight in gold, and their salaries reflect that.
Think of software like building a skyscraper. Low-cost developers have learned how to poor cement, place rebar, and decorate a pretty facade, but don’t have extensive training in large scale mechanical stresses, foundation design, and resource management. The building will look fine for a while, but as it grows the cracks will show and eventually it will fail and need to be rebuilt.
Not all languages and frameworks are equal
Every development team has their favorite programming language and frameworks, and they will likely give you reasons why you should allow them to build with that language or framework. While it’s true that most code behaves in roughly the same way, your job from a business perspective will be to support this application long term. That means your project needs to be written in a language that is popular, and likely to be around for a while. The developers may love a new fad language that’s just “so much better” than the older languages, but if the new language dies out in six months you now have to A) stick with that team forever, or B) find some other shop using this niche, probably expensive language.
We encourage you to research application languages and frameworks on your own, but this 2021 Stack Overflow survey is very helpful.
Your business needs should be defined
Think long and hard about what problem you’re solving and how much money you’re losing by not solving it. You don’t have to know HOW software will fix the problem, that’s for the development team to figure out, but you do need to know WHAT problem you’re fixing and how much money that fix will save you over time.
If the team doesn’t actively understand and work towards solving your business problem, get a new team.
On the flip side of this, understand that business problems have a lot of solutions, and the most appropriate solution may not involve the specific technology you have in mind. Our team regularly encounters buyers who insist that they need an app yet describe a business problem that does not fit a mobile app delivery model. The best project outcomes occur when business experts focus on business problems and technology experts focus on the best technology to solve those problems.
Software projects don’t end
This is another misconception that tends to blindside buyers. Most people assume that a project will start on a specific date, run for a specific time, then end. But the reality is that software expenditure ends when the problem no longer needs fixing. At a minimum, the software will incur monthly hosting and maintenance costs. You cannot leave modern software without maintenance because there are so many connections to other applications that any number of external factors can destabilize your system. Your system will need to be actively monitored and fixed as errors occur.
However, errors aren’t the only things to consider. Most projects end up identifying other business issues beyond those originally in scope. Virtually all businesses have an ever-increasing backlog of business problems to solve, each with a corresponding increase in revenue or decrease in expenses.
If the business problems are being solved properly, the economical solution is to continue development indefinitely.
You MUST be hands on
Custom software products are, by definition, creating solutions to non-standard problems. If the problem were standard, there would already be a software product available to solve that problem. That means that the quality of your solution will depend entirely on how clearly and frequently you can communicate your business problem to the development team. Nothing predicts negative project outcomes like buyers who are not willing to be involved with their custom solution.
Think of it this way, if you had an idea for a brand-new car that doesn’t behave like any car in existence today, would you assume that you could describe it to engineers one time and then come back in a few months and have the perfect car? No, you would need to constantly discuss the new functionality you want and sign off on changing the functionality that may not be possible.
Common terminology all software buyers should know
Knowledge of common development terms can greatly increase your understanding of the project, as well as the competency of your potential development partner. There are nearly endless development terms, but we’ve done our best to choose those that most apply to team’s ability to produce quality work.
Agile
Agile is a software development philosophy that focuses on iteration, quickly assessing new information, and changing directions as needed. Methodologies that use Agile principles are proven to result in better project outcomes over a shorter timeframe.
DevOps
This term is used to encompass a wide range of activities surrounding the successful operation of development teams. DevOps is concerned with making sure code is deployed consistently, with minimal bugs, and with many contingencies to prevent system failures. Robust DevOps practices are mandatory for large, enterprise applications.
Environment
In software development, the “environment” typically refers to an instance of the system that is set up for a specific purpose. Environments allow the engineers to change specific variables for various stages of the development process.
Development Environment
This is where engineers modify and expand code. Development environments are typically unstable due to large scale changes, and 3rd party integrations (particularly those that charge money) may be disabled.
Test Environment
This is a more stable version of the system where manual testing can happen. It’s built to simulate what active users would see and is generally more stable than the development environment. 3rd party systems may be active at this stage to fully simulate the user experience.
Production Environment
This is the version of the system that users see and interact with. It contains live data and outages are considered critical. No changes should be made directly to this environment without first going through a review and testing process.
Scrum
Scrum is one of the most popular methodologies that uses Agile principles. In this methodology, the team commits to a set amount of work in fixed periods of time called “sprints”. The work is then evaluated, and a new set of work is chosen for the next sprint based on the results of the previous one.
Version Control
Technology used to update the code base in a controlled and reversable way. Code bases that are version controlled can easily be “rolled back” to a previous version if a mistake is made. Virtually all modern code repository tools will use some form of version control to protect the code base.
Automated Testing
Software systems are wildly complex and contain too much functionality to test manually. To deal with this, engineers write small pieces of code that test the functionality of the code that comprises the system. These tests run periodically and let the engineers know if any of the system code changed in a way that broke functionality. When that happens, a report will tell the engineers where the failure happened which lets the system be fixed much faster. Below are some examples of specific types of automated tests.
Unit Tests
Tests designed to validate that individual “units” of code still run properly. For example, a unit test may validate “XYZ unit of code always generates an even number”.
Integration Tests
These tests ensure that large modules of functionally within the system behave properly when combined. For example, an integration test may validate “Module X and Module Y do not product errors when run together”.
End-To-End (e2e) Tests
These tests simulate a user in the system by testing functionality from the standpoint of the UI. While these tests more accurately represent the real-world usage of the system, they are more expensive to build, slower to run, and more difficult to change. Because of this, engineers may choose to use them sparingly. An end-to-end test may validate “When the user clicks on X page element, the page navigates to Y page”.
Repository
A place where all the code in the application is stored and updated. Typically, this is cloud hosted and accessible anywhere.
Sprint
A sprint is the period of time in which a team will work on a set amount of work. Sprints periods are anywhere from 1-4 weeks, however 1-2 week sprints are generally considered the most productive.
Test Driven Development (TDD)
Test driven development is a coding practice in which engineers write the automated tests before writing the functionality. As the functionality is being written, the automated tests will continually tell the engineer if the new code is correct. This is generally considered a more advanced technique but results in extremely well written and tested code.
Language
The way in which individual lines of code are written. Similar to traditional human languages.
Continuous Integration and Continuous Development (CI/CD)
CI/CD is a series of automations and activities designed to move new pieces of functionality through a “pipeline” of validation and testing before ultimately being deployed for users to experience. The CI/CD process is one of the primary concerns of a DevOps practitioner.
Framework
A collection of pre-build functionality, written in a specific language, that encourages developers to build a system using known patterns. For example, applications using the Angular framework are written in the Typescript language. The Angular framework provides pre-built tools, written in Typescript, that only work properly if used the way the Angular framework developers intend for them to be used. Frameworks allow teams to move much faster, but occasionally present development challenges if the project calls for functionality that the framework does not support.
Monitoring
All systems experience errors, regardless of how much automated testing is done. When these errors happen in production the system needs a way of reporting what went wrong, when it went wrong, and who was affected to the development team. Monitoring software is installed within the system code to generate these reports and send out alerts when critical errors happen.
Tech Stack
The “stack” refers to the collection of technology used in each of the layers of the application. An example of a tech stack would be “Angular, .NET Core, and SQL” which means that the front end of the application would be written in Angular, the API/middle layer would use the .NET Core framework, and the database would be a SQL database.
Front End Layer
The “front end” refers to the technology used to produce the part of the system the user sees and interacts with. This can refer to website tech or mobile app tech.
Middle Layer
The middle layer or middle tier is the part of the application that acts as the “brain” of the system. It makes decisions about what information is sent to the front end, how information is transformed, and what information is sent to the database.
Storage Layer
This layer houses data long term. When a user makes a request via the front end, the middle layer interprets this request and retrieves data from this layer.
Key questions for potential partners
Questions are an absolutely vital part of the process. With the success of your project riding on both parties understanding of each other’s needs and capabilities, the only “bad” question is the one not asked. We’ve provided some example questions to get a feel for your partner’s capabilities, but we encourage you to think of more and ask away.
“Will I have access to the team’s planning tools?”
Teams should be using some sort of centralized place for organizing the current work (essentially a group TO DO list), and you should have access to it. You are paying a lot of money and you deserve to have work visible to you.
“How will I check the quality of the work during development?”
Again, work needs to be visible. If you do not have a way to test or view the system than you cannot confirm that the correct work is being done. Rewrites are expensive. Its your job to provide rapid and frequent feedback, and it’s the development team’s job to make it easy for you to see your system. Most firms should create a test environment for you to play around with as the system is built.
“Will I have access to the repository?”
Its your code. You paid for it, you own it, and you should have access to it. Larger, more established firms may simply write into the contract that you own all the code and provide access as needed. However, if you’re dealing with freelance engineers, or otherwise less established businesses, always ask for admin access to the repository so that you can remove users and retain your code.
“Who owns the IP of the code generated, and is it specified in the contract?”
This is a highly complex issue that will likely require further research on your part. However, in general you will want to make sure that the code used in your system is either written by your team or open source and legal to use free of charge. You will also need to make sure that all code written by your development team is completely and totally owned by you forever.
“What is your preferred tech stack?”
They should be able to answer what their preference is, as well as if they’re able to use other technology beyond their favorites. Do your research on the technologies they use and try to avoid niche languages and frameworks that may hurt you in the future.
“What is your automated testing process like?”
At a minimum they should use unit tests and LOTS of them. The more they can speak on testing the better. Companies that use unit, integration, and end to end testing while practicing test driven development will likely produce extremely high-quality code but will be more expensive than other companies. In general, automated testing slows development up front, but saves huge amounts of money long term. If your project is quick and not very complex, you’ll likely be ok without much automated testing. If you intend to build large, enterprise system, testing is a must, and your development partner needs to be capable of building those tests.
“What is your CI/CD process like?”
Ideally the process will involve a test or staging environment that is not public. Releases should be frequent and automated tests should run as part of this process. This process should also provide a quick way to revert back to previous versions of the system in the event of a critical error making it into the production code.
“What is your work methodology?”
Good processes are arguably one of the most important determining factors in the success of a team. If a development partner cannot accurately describe the process by which the team completes work, you can bet that development will be slow and poor quality. Amongst defined development methodologies, Agile centric methodologies have been proven to be the most effective as they promote strong communication, frequent evaluation, and rapid adaptation to new requirements.
Did you get all that?
This is a massive topic and unfortunately this ridiculously long blog post doesn’t even scratch the surface. However, we hope that this information was thought provoking enough to serve as a starting point on your journey, and to help you feel more confident and more capable of working with a team.
At Sigao our mission has always, and will always, be to leave our partners better off than before they met us. If you have any questions about this topic, feel free to comment below or give us a shout directly.
