Atlantic Business Technologies, Inc.

Author: Matt Lemke

  • What should a software development contract look like?

    What should a software development contract look like?

    The reason to start any relationship or partnership with a formal agreement is to create a backstop, ensuring all legal expectations are covered and compliance needs are met. A software development contract provides transparency and protection for businesses and their development partners.

    Plainly defined terms should keep a project moving forwards and align expectations between both parties. In the worst case scenario, you may need to refer to the contract to prevent a disagreement from becoming an expensive lawsuit.

    What’s included in a software development agreement?

    As we discussed above, it’s important to make sure there is a sufficient legal backstop should things not work out with a vendor. But this is a rare use case. At Atlantic BT, we primarily use contracts for setting expectations. 

    Some elements you should expect in a contract include:

    • Governing legal jurisdiction
    • Separation or termination terms and costs
    • Ownership of the code
    • Definitions of acceptance 
    • Authorizations for points of contact

    If any of these baseline elements are missing from a contract, you may want to find a new software development partner. You risk finding yourself exposed to legal challenges of code ownership, expensive or combative separations, or having to litigate in a different state than where you are incorporated.  

    What are some examples of red flags?

    The most obvious red flag for a software development partnership would be the lack of a formal agreement. Some developers are not sophisticated enough to hire lawyers to generate professional and legally binding contracts. Without a contract, you are opening your business up to unnecessary risk of employee solicitation, customer solicitation, unfair billing practices, or liabilities for licensing/payments that are unexpected. 

    Another common issue would be businesses hiring offshore developers or third-party contractors without transparency. Look out for language around including subcontractors without approval or awareness. Some “software development agencies” may not actually have software developers on staff at all. If they’re hiding this fact, there’s a chance the outsourced development is low cost and low quality.

    Also be wary of hidden licensing and termination clauses. Make sure you know what you own at the end of the agreement and how costly it may be to get out of it. 

    Finally, find out how code is deemed “acceptable” for a project. Software development companies should have formal acceptance procedures which outline standards for quality, security, and user experience. 

    What can you expect from an Atlantic BT software contract?

    As a software development company, our primary goal with our client contracts is to be flexible and create language that both sides deem fair and balanced. This is the basis for delivering quality software that you can own and can be proud of.

    We are even flexible to use your contract as a starting point and refine until we are comfortable with the language and terms. 

    Here’s our process for starting partnerships.

    NDAs protect intellectual property.

    Engagements begin with a straight forward mutual non-disclosure agreement (mNDA). Now, both parties are protected from disclosure of intellectual property and trade secrets. 

    A Master Services Agreement defines legal parameters.

    We then move into the Master Services Agreement that helps define the legal jurisdiction and other parameters that help govern the partnership. This includes items like flexible payment terms, acceptance, warranties, liability, terms and termination, intellectual property rights and exclusions, third party software, non-solicitation, indemnification, and the other legal essentials.

    Statements of Work and Retainers govern development.

    There are then two types of contracts that govern the actual development work: Statements of Work and Retainers. 

    Statements of Work outline defined projects.

    For Statements of Work, we work in a decent mix of planning and agility. While the project is defined, we know businesses have shifting priorities over time. Statements of Work can be augmented during the project lifecycle with change orders and email approvals.  

    Retainer Agreements handle shifting needs.

    We create Retainer agreements in one of these scenarios:

    •  There is a need for staff augmentation
    • There are many shifting initiatives that are not clearly defined 

    Retainers have defined budgets, roll over hours, and flexibility to grow and shrink with some notice. 

    Ready to start a software development project?

    Finding an agency that is trustworthy and transparent in their contracts is the first step towards building a partnership. If you have any questions about our process, we’re happy to talk.

  • Break free of CMS constraints.

    Break free of CMS constraints.

    Your content management system is meant to empower you, not limit you. A CMS should facilitate content creation for those who don’t code. It can include permissions, workflows, and elements of page design. 

    Unfortunately, many businesses start to feel restricted by their CMS as they grow. Atlantic BT has seen cases where companies spend weeks creating key pages, lose money from downtime, experience security breaches, or lose organic traffic as the website grows slow or outdated.

    These issues are preventable and should not be the norm. By selecting the best-fit CMS for your requirements and following key principles, you can have all the flexibility needed to help your business grow. 

    Here’s how to ensure your CMS is flexible and capable of supporting your business needs.

    Choose the most beneficial CMS to start.

    Some popular CMSs include WordPress, Drupal, and Umbraco. In certain use cases, companies are also starting to go headless. A Headless CMS requires more technical knowledge, but gives unlimited flexibility. You can publish content in one place, and have an API query the content anywhere (like a website or mobile app).

    The process of selecting the best CMS includes a careful examination of business requirements. For example, if your business includes a custom developed feature like a unique checkout process or customer portal, an Umbraco CMS could facilitate the integration with your website. On the other hand, a large website without proprietary software integrations may benefit from a WordPress CMS.  

    Atlantic BT helps you identify and prioritize needs, performing a comparative analysis of a subset that most closely matches your criteria. This method is similar to a personalized magic quadrant analysis. 

    Incorporate modular design.

    A modular design means using repeatable elements, or components, to build pages.

    This method empowers both non-technical users and developers. Developers have a library of components available to quickly create new page templates. Users can rearrange, include, or exclude these components within a template to design and publish new pages.

    Now and then, there may be a request to design and develop a new component. But this is much faster than designing a new page template altogether.

    Modular design can also facilitate the balancing act of flexibility and brand constraints. When employees can select various pre-designed elements to build a page, they have freedom to choose some elements. They do not have the freedom to customize design to the point that they are overwhelmed by options or straying from brand standards. 

    Ultimately, the process of creating pages is simplified for those who cannot code, and the process of creating new templates is faster for developers.

    Make smarter choices about flexibility.

    A website cannot be completely flexible for all content, design, features, and scenarios. That’s because with more user flexibility comes more complexity in writing and managing code. 

    Too often, people choose to build for flexibility due to fear of commitment. They don’t want to make a design or data decision, so they choose to build in a way that they don’t have to. The result: unnecessary complexities that are not worth the investment to build.

    You can avoid this fallacy by correctly determining which elements of a website need to be flexible. Maybe a blog layout can be simple, but a landing page for PPC campaigns needs the ability to test many different forms and layouts.

    Atlantic BT incorporates this step in the requirements gathering phase of a new project. Many people find that relying on an unbiased external team is beneficial to this process. 

    Continue to customize and update.

    Set yourself up for success! Even if you have your bases covered, you should constantly invest in enhancing your CMS. 

    Foster a culture of continuous improvement in your company and continue to test your website’s limits. As your business changes, you may choose to add new features like a storefront, custom dashboard, or online course library. If you lack the skill set or resources to continue to customize, you can always find a partner who can supplement your team.

    Additionally, keeping your CMS up-to-date will ensure you won’t accrue technical debt. Keep your site secure and performant by completing framework updates, updating underlying software packages, and updating server hardware. 

    Atlantic BT has seen websites last far beyond the typical 3-5 year mark due to ongoing maintenance. When you think about it, the best websites never stop the development and improvement process.

    Are you feeling limited by your CMS?

    If you’re feeling stuck, the solution might be to migrate to a new CMS or add custom elements to your current framework. Either way, we can help you get there. Reach out for a free consultation with one of our experts.

  • How to balance technical risk and innovation.

    How to balance technical risk and innovation.

    While following strict corporate regulations makes sense from a risk management standpoint, it can be debilitating to innovation. 

    Issues like regulatory compliance, privacy protection, and data security result in a plethora of processes and policies to reduce risk. Unfortunately, this red tape also slows down the hiring, development, and technological advances needed to move business forward.

    Processes slowing change is especially dangerous if technology is part of your competitive advantage.

    So how can you combat a culture of limits and protect your core competency?

    Recognize the dangers of technology complacency.

    What happens when your technology is stagnant? Your organization’s growth is hindered due to these issues.

    Low employee morale.

    Outdated technology can make you feel stuck. Employees may no longer enjoy working within an application and feel frustrated leveraging it to perform needed tasks. They may not be able to find needed information with poorly connected systems, which weakens decision making.

    Feeling limited can lead to turnover, a lack of creativity and initiative in employees, and ultimately less innovation.

    Increased technical debt.

    Not only does outdated technology hurt morale, applications will incur expenses from technical debt. Past decisions that were meant to eliminate risk prove harmful over time. This may have been a quick security patch or the decision to delay a helpful feature.

    Missed market opportunities.

    What are the costs of going through your business strategy with slow technology, security gaps, or a poor user experience? You may opt to forgo some opportunities all together, giving your competitors an instant advantage.

    Find ways to foster innovation in a regulated environment.

    These two simple changes to a company’s culture can start remedying the harmful practices that slow you down. 

    Encourage people to take risks and allow for mistakes.

    While industry regulations will always be a requirement, there may be some other areas where risks are permissible. 

    Bizjournals.com states:

    Roger Perlmutter, the new research and development director at drug giant Merck, gives leaders and their teams the opportunity to take chances without punitive risk. Most wrong decisions at low- to middle-management levels won’t kill the company, and when people engage and take full ownership of their jobs, the result may yield something wonderful.

    Create a culture where partners assume some risk.

    You’re the expert in your industry and business model, but a partner can specialize in the necessary development piece. 

    Find a partner who can focus on the complex technical pieces of a project, assuming the risks of development time and budget. This partnership should empower you to focus on higher level strategy.

    For instance, in this example with Mutual Drug, Atlantic BT handled contracting an established 3rd party CSOS auditor to evaluate their application. We then performed multiple internal audits and tests to save our client the significant costs of multiple official audits. 

    Handling the nitty gritty back and forth and auditing gave our client some peace of mind. The partnership ultimately led to a stronger, streamlined, and compliant new application that launched their business forward.

    Feeling stuck with your technology?

    Many businesses come to Atlantic BT for help when they feel limited by their mission-critical applications. We can help by integrating systems, recommending the best way to spend budget, or building new features. 

    But most importantly, we understand the nuances of industries with strict policies. That’s why we create flexible processes that work for you – in terms of billing and accounting, development, deploying, and project management.

    Reach out to one of our experts to learn more about how we can help.

  • Failed RFPs are expensive. Here’s how to find better vendors.

    Failed RFPs are expensive. Here’s how to find better vendors.

    When you find yourself in a scenario where custom software is essential, you have three options:

    1. Develop the custom software in-house.
    2. Find a partner to handle the entire project.
    3. Partner with a vendor who integrates with your team.

    This middle ground of working closely with a vendor leads to writing an RFP and evaluating responses.

    Why do RFPs fail?

    Many RFP partnerships fail due to poor vendor selection or unclear project requirements and deliverables outlined. You may have even lost faith in the process of trusting partners altogether.

    Consider that it might not be the RFP process that’s failing, but rather using outdated methods for evaluating your partners. After all, they’ve probably responded to enough RFPs that they’ve learned what you want to hear at the surface level.

    Try these evaluation tactics to dig deeper and choose better partners.

    1. Stop using price as a measure of quality.

    We are trained to believe that price and quality is a linear relationship: the more you pay, the higher the quality and the less you pay, the lower the quality.

    However, price is not exclusively tied to a company’s output. It’s also closely tied to internal efficiency and how streamlined internal processes may be.

    A vendor who has found a highly efficient way to produce a quality product may have the same price as a company who cuts corners to produce a low quality product.

    According to CIO.com, “The highest priced technology partners often spent longer amounts of time on the project, with too many unnecessary staff members and account managers. On the other hand, the lower end of the market often lacked the skill and technical ability to produce consistent quality.

    Picking a technology partner is a completely different experience than shopping on Amazon. You cannot go to a vendor and simply pick the lowest price for the exact service you need. It can be a nuance-filled and complex process.”

    For this reason, your perfect partner is likely in the middle ground of high and low price.

    2. Rely on references over examples.

    Most organizations like to see vendors’ examples of past work and testimonials to help them evaluate expertise. This may come in the form of case studies or quick client quotes.

    The problem is, these are surface-level validators that can skim over some of the important nitty gritty. You’ll want to take a step further. Always ask for references to discover:

    • How the vendor handled issues that arose during the process
    • How the vendor performed in terms of budget and timeline
    • If the final product was satisfactory and truly provided business value

    3. Look for a warranty.

    Vendors who truly believe that their services will be satisfactory will offer some sort of guarantee. This may be in the form of month-to-month contracts, commitment to fixing bugs for free, or free work when a project exceeds budget.

    4. Seek vendors with flexible processes.

    Is your vendor the same? What happens when two rigid organizations work together? Look for a partner who can mold their development, deployment, project management, and billing processes to fit your organization’s standards.

    Need help with custom software development?

    Whether you need help defining business requirements, writing an RFP, or are in the stage of looking for vendors; we’d love to learn more and see how we can help! Get in touch for a free consultation.

  • Recognize and fix different types of technical debt.

    Recognize and fix different types of technical debt.

    I have been thinking a lot about technical debt lately – weird I know, but these are the things you think about when you deliver code to customers that power their businesses, digital initiatives, and websites. 

    I am also celebrating with our IT Team the decommissioning of our datacenter footprint. For decades, we had physical servers running in a local datacenter. As we deployed new projects to AWS; we let our servers and equipment age out, running fewer critical services on it over the years. But back to the point…

    What the heck is all this technical debt?

    Traditionally, technical debt means that choosing a quick and easy solution now reflects an implied cost of additional rework down the road. Without recurring updates, any software can incur technical debt over time.

    It’s a bit easier to think about technical debt in terms of physical infrastructure or hardware. Think of your phone or laptop. While it may be shiny and new now, in a few years it’ll need more memory to even browse the Internet (we will cover PWA’s and SPA’s in another post)… or the phone may need to be replaced altogether. 

    What kinds of technical debt are out there?

    Here at Atlantic BT, we have to think not only about technical debt in the cloud servers we run, but also in the code that powers the web-based software we build. The technical debt in code is a bit more abstract to think about. 

    Over the years, we have learned many IT tricks to keep legacy code stable, maintain security, and keep applications resilient. Implementing these tricks can be highly effective in extending the lifetime of the application. 

    However, nothing lives forever, and applying these techniques can be misleading. It’s possible to actually hide the growing technical debt accrued due to advances in the surrounding technical environment. 

    Technical debt in software design.

    There is a lot of talk about the tradeoffs at the software design stage of a project and how that translates to technical debt – while that is where the debt starts, it’s usually easier to manage at that point. 

    Planning is critical. That’s why we take a preventative step of having developers discuss solutions with a team, write out their feature specifications, and create acceptance criteria.

    Technical debt in software maintenance.

    The technical debt that I want to focus on is the kind where we don’t invest in properly maintaining software over time and how that builds the technical debt snowball. We all have those skeletons in our proverbial IT closets… those applications that only one person actually knows how to build, deploy, and support. The ones we leave out of our DevOps pipelines because the systems can’t handle infrastructure as code. 

    This debt builds over time and if not addressed can lead to issues in recovery time objectives (RTO) or recovery point objectives (RPO) in disaster recovery and business continuity plans. 

    You will incur all sorts of costs: time, inability to deliver business value, security, or reliability. Some of this technical debt may exist in legacy applications where you are also having a hard time finding quality candidates to support or change these applications.  

    What kinds of decisions create technical debt?

    In my opinion, technical debt is simply a tradeoff between money, time, and objectives. It’s like the PM triangle of speed, budget, and quality where you can only pick two options for your project.

    These types of decisions will affect technical debt, creating high risk and future costs:

    • Not investing the time to bring in a diverse team to design software.
    • Not investing time in refactoring something that works to make it more testable or elegant.
    • Not spending time on documenting the feature specification and acceptance criteria for a story and jumping right into writing code.
    • Not spending time thinking about security. 
    • Not leveraging real enterprise design patterns to build new components based on legacy decisions. 

    At the end of the day, technical debt is simple: it comes down to money over time, just like debt in real life.

    What can I do to assess my current technical debt?

    The best way to get a handle on technical debt is to audit your application stack, IT infrastructure, and business processes. Look for weakness in the observability of the security and health of these items.

    With today’s continuous integration systems, it’s fairly straightforward to assess your core code with static and dynamic analysis, Linting, and unit test coverage reporting. There are also many tools to facilitate, such as visual regression. 

    Microsoft author Paul DiLascia wrote an article that offers these guidelines for good code:

    • Simplicity
    • Readability
    • Modularity
    • Layering
    • Design
    • Efficiency
    • Elegance
    • Clarity

    A third party code audit can help you gain insight with a fresh pair of eyes. Assess whether or not your code possesses the above traits, shedding light on documentation weakness (both within the code and in user guides) and other poor coding practices.

    A third party can also have conversations with your stakeholders or internal teams around coding practices, software development methodologies, CI/CD, and DevOps.

    How do we fix technical debt?

    Like any debt, technical debt needs to be calculated before it can be fully addressed. Once the magnitude of the technical debt is known, it’s all about time and money.

    Start crafting a plan to address technical debt in core areas of the business that generate revenue, provide your X factor, or support your team.

    There is no simple answer, but today’s IaaS, PaaS, code frameworks, and developer tools all provide jumping off points that can mitigate technical debt while allowing you to focus on your core business.

    Part of our business is helping you in this area. So if there is any acute digital pain or technical debt you’re experiencing, let’s have a conversation!

  • How do I calculate the ROI of a new website?

    How do I calculate the ROI of a new website?

    If you’re contemplating changes to your website, it’s crucial to first understand the web design cost associated with making those changes. This understanding will allow you to calculate the potential return on investment (ROI), helping you determine whether the proposed changes will be beneficial to your bottom line.

    The average lifespan of a website is 3-5 years. After this period, aspects such as design and device compatibility may become obsolete. However, Atlantic BT has seen websites last much longer. That’s because these custom web projects include ongoing maintenance:

    • Framework updates
    • Updates to underlying software packages
    • Server hardware updates (or migrating to AWS with a well-architected framework and careful attention to workload-specific services)
    • Continued design and user experience tweaks based on data

    It takes a continued investment to maintain a reliable, secure, and performant website. In reality, these long-lasting websites have never really never stopped the development and improvement process. We like to implement new technologies and constantly experiment to stay current.

    Is experimenting with new technologies worth the investment?

    You are faced with two options: overhauling your website every 3-4 years or investing in continuous enhancements. Your decision ultimately depends on which option gives you the highest ROI. 

    Let’s say you are at year 2 and start to see the benefits in switching your platform. How should you calculate ROI for the investment? 

    Frame your mindset in three simple questions:

    1. How much does my website impact my revenue currently?

    It can be challenging to measure revenue if you aren’t directly selling products online. In businesses outside of eCommerce, it usually boils down to analytics and recognizing patterns in inbound leads. 

    Do 100% of your leads come in digitally? How does word-of-mouth impact your leads? Are you doing any other non-digital or traditional marketing?

    2. Is my website an important tool in my strategy going forward?

    What is my digital strategy moving forward, and how does my website play into it? Will you be driving ads to landing pages, hosting whitepapers, or creating a login portal for customers to self-serve?

    Take some time and determine how much your website will contribute to revenue growth.

    3. What are the opportunity costs of waiting?

    Now that you have determined how you will leverage your website, calculate the opportunity cost of going through your strategy with outdated technology aging web designs or a poor user experience.

    Would you benefit from going headless? What will happen if you skip Drupal 10? Will your WordPress site face security risks from skipping the next update? Do you have a way to draw insights without a custom dashboard? Are customers using a mobile device to access my website?

    Recognize hidden opportunity costs.

    Answering these questions is just the beginning of the journey as the need for change on digital platforms gains momentum. Here is a breakdown of opportunity costs we see companies missing when they wait too long to update.

    Next-level technology becomes more accessible to you and competitors every year. 

    We are seeing upticks in both velocity of framework changes, number of frameworks and languages available, and persistent threats to common web technologies, and groundbreaking Artificial intelligence as a service (AIaaS) platforms. This is all being powered by the underlying “law of accelerating returns” of technology.

    The power that we can harness from the underlying systems to run software, leverage machine learning, and fight off bad actors is growing alongside the speed of the processors, the speed of the networks, and the companies that are allowing us to consume this power in minute-by-minute cost structures. 

    The web design cost of rebuilding increases as technology becomes more outdated.

    The older a site gets, the older the technology used to build it is. A feature to be developed could be 25-100% more expensive to build. Over the total cost of ownership of a website, there will be a tipping point that rebuilding now is more cost effective than not. (Think how costly repair costs can be on very old cars or slightly old cell phones). 

    The cost of internal productivity.

    Your company is likely to interact with your website much more frequently than any individual customer/user. For this reason, the actual productivity of your employees is going to be negatively impacted along the age of the application. 

    If a rebuild can increase the performance, improve the usability, or automate some aspects of your site, you could potentially offset having to hire additional staff. 

    The cost of falling behind user expectations.

    The internet has greatly accelerated the pace of change in user behavior and expectations. As the chart below demonstrates, waiting five years between updates can lead to missing or being late to adapt to major user behavior changes. This is an excerpt from the  Forrester Research report, Winning the new B2B Buyer, 2020.

    The cost of not prioritizing experience. 

    With an increasing shift in the balance of customer interactions from personal to online, the online experience you provide to your customers is no longer a nice-to-have, but an essential part of the experience your customer has with your business.

    “Experience-Driven Businesses report driving faster topline growth, with an average revenue growth rate of 15%, compared to an average of 11% among other companies in our survey.”

    “Experience-driven businesses grew revenue 1.4x faster and increased customer lifetime value 1.6x more than other companies in the past year.”

    Forrester Research, The Business Impact Of Investing In Experience, April 2018

    Ready to get started?

    It is our opinion that you should not wait to get started on any digital  journey and you should always experiment with new technology. The web design cost ROI, if you choose wisely, will be measurable. Contact us for a free consultation to get started strategizing.