Our Playbook.

What Can We Do For You?

Echobind is a full-service agency. Every new engagement starts with asking questions to better understand our client objectives. Our team needs to be able to explain how your business works, how software is used within your organization, and what successful engagement looks like.

What makes our team unique is that we either establish a clear path for a return on investment before we start working on a project, or we recommend to our clients that they reconsider their request and focus their investment elsewhere since the return isn't there. And if we can't help you, we'll find a team that can.

Here's a list of our most commonly offered services:

• Strategic Planning
• Software Audits
• Creative
• Design / User Experience
• Engineering
• Quality Assurance
• Team Augmentation
• Project Rescue

We’re here to help fill the gaps required to finish a project or begin new, more ambitious projects. This can take the form of us joining your current developers and working within your existing project management ecosystem. This type of work arrangement can range from a brief consultatory code review to a long-term joint development effort.

From Idea to App

This is our start-to-finish plan for transforming your ideas into a fully realized, production application.

The Initial Call

It's always a big step to begin a new relationship with an agency; how do you know if they are up for the job? At Echobind, we're more than happy to talk through your project and see if we're a good fit for your needs. During that initial call, we'd do thorough rundown of your business and the project so that we could understand exactly what you're looking to achieve and how we can help. We, as much as you, want to ensure that we're the right partner for your needs and that it is a mutually beneficial relationship.

How We Estimate

With a large number of projects under our belt, we've had the opportunity to hone our estimation process. We start by having two senior engineers give their estimate for the project. Equipped with those two estimates as well as knowledge and experience from previous projects, we put together a final, single estimate. When we share our estimate with you, we make sure to include a contingency based on any unknowns of the project.

Once development gets underway, we revisit estimates during each sprint to ensure accuracy and to account for any new knowledge or factors that may affect the estimate.

Signing an MSA and Our First SOW

Before we begin work, we will send our standard Master Services Agreement (MSA) which outlines the terms of our working relationship and sets expectations. Once that and the Statement of Work (SOW) agreement are executed, we can begin the project. Typically, we like to start with a small SOW because it gives our teams a chance to get to know each other and ease into our working relationship.

We can work with however many of your team members as you'd like and as makes sense, but we recommend and ask for a primary point of contact for decision making power. You'll notice this is actually listed in our MSA because it makes communication and decision making incredibly effective.

Account Staffing

Once we have the SOW, we are able to begin selecting the team members we'll assign to your account. Among the factors we consider are the technical skills required, team availability and geographic location. We may occasionally rotate people on accounts, which is done intentionally and with purpose. We do this to make sure that you always have the right team for each stage of the project (they're fresh, they have the right expertise for the challenge at hand, etc).

The Project Kickoff

Every project starts with a kickoff, and we do our best to make sure these kickoffs happen in person. In person kickoffs are so important to us that we'll foot the bill for sending our team to come to meet you. In person kickoffs allow for the clearest and most thorough communication - we cover the most, are able to ask clarifying questions and can ensure we leave no stone unturned before we hit the ground running on a project.

A typical kickoff lasts an entire day. During this time, we'll introduce team members and talk through roles and responsibilities, discuss the product vision, and agree on what success looks like at the end of the project.

During this meeting, we discuss the project and how it relates to the business. We also talk about use-cases, product validation, and the project’s overall goals. This conversation enables us to produce a project roadmap that details the project’s timeline and helps ensure its success.

A roadmap looks like this:

User Flows

When looking at user flows, we are looking at the series of steps a user takes to achieve a specified goal. It answers the questions of what the user is trying to accomplish, why it’s important, and what the barriers may be.

User flows serve as the basis for content requirements on each screen of the app. When mapping out each flow we reduce the risk of potential hidden unknowns that could have a significant effect on a project's estimate. With the user flows in hand the designer has a clear map of what users should be able to accomplish and can use this in the next step of the process: wireframes.

Wireframes

Creating wireframes is the process of taking the established user flows and creating the visual blueprints of an application that will facilitate them.

Depending on the individual project needs, either high or low fidelity wireframes are created. Low fidelity wireframes are very generalized outlines of the potential product, with many representative structures used which may bear no resemblance to the final designs. High fidelity wireframes are much more detailed, and often include some of the final design elements such as typefaces, icons, and the desired color contrasts represented in grayscale.

This is an exploratory process, with multiple ideas often sketched for the same objective. This creates an array of options from which the designer will ultimately create the optimal user experience (UX) via their final design.

Design

In the design phase, the designer will take the wireframes and create a full physical representation of the final product, as close as possible to its final appearance. All final design elements such as logos, color schemes, typefaces, etc. are selected in this phase and incorporated into the final designs. Some considerations taken by the designer include:

• Adhering to any existing brand identities.
• Establishing the unique identity of the final product.
• Seamlessly tying all visual elements together into a cohesive user experience.

User Stories

We craft User Stories right before Development so that we can leverage everything we've learned from the process thus far - like leveraging User Flows and Design. Waiting until just before coding begins ensures we don't spend valuable time going back and forth to update the Stories as requirements change and it also helps us avoid significant changes to the SOW. User Stories are the "source of truth" for Development and for what the final product should accomplish.

Development

With the user stories and final designs in hand, we can begin writing the actual code of the final product. Our team typically follows the Kanban methodology, which emphasizes continual product delivery. We operate in one-week sprint cycles, with development tasks tracked on a Shortcut board, connected directly to the project’s code repository on GitHub.

We strive to spend minimal time in meetings, even deferring from daily standups, and instead allow team members to organize and collaborate organically. This helps us to maximize the productivity of billable hours.

At the end of each sprint we hold a brief review, to share what was accomplished and if anything needs to be carried over. We strive to set realistic objectives for each sprint, but cannot guarantee 100% completion of all tasks. We continue this process iteratively, with our current progress always transparent. See a more in-depth look at our Code Process below.

Quality Assurance (QA)

The Quality Assurance phase is our internal series of testing to ensure the product meets all design and user story requirements. The product is usually tested in an isolated QA environment, established to mirror the anticipated conditions of the production environment while being uninfluenced by external parameters. Any testing criteria which is unmet is sent back to the development team as a bug, and incorporated into any ongoing sprint cycles, or resolved in a separate “bug fix” sprint.

User Acceptance Testing

UAT is your testing phase. After the product has passed our internal testing criteria, it is deployed to a UAT environment. The UAT environment is to the QA environment is that the QA environment is limited to the Echobind team while the UAT environment is what we give you access to. Often, this environment is used to expose the app to a sample of test users to gather their general impressions. In UAT, you will test and evaluate the product and confirm that all product requirements have been met. This is an opportunity for you to call out any concerns or change requests prior to deploying to production.

Launch/Production

Once you are satisfied with the UAT deployment of the product we discuss a production release schedule. This is the phase at which the product will be deployed to its final environment and delivered to its end users, and integrated with any external systems or applications.

Production releases inevitably introduce a degree of variability, as the deployment environment is usually exposed to more outside influences than the QA or UAT environments. Upon a successful production deployment, smoke testing occurs promptly; a light battery of tests to ensure that there are no deployment issues that could affect the end-user.

Given this increased degree of variability, it is recommended that production deployment does not occur on a Friday so that at least a full day can be provided to resolve any issues that may arise.

Release Maintenance

Once in production, the application will be considered “completed”. As time passes though, to ensure future maintainability, we are happy to periodically update open source dependencies, resolve any bugs that may arise, and develop additional functionality. Some of these dependencies provide critical functionality to the application. If not maintained, the application is at risk of security vulnerabilities and won’t take advantage of future improvements. This could result in serious data loss or exposure of sensitive information. Keeping dependencies updated reduces our risk to security threats and maintains functionality. We only use modules that are regularly updated to keep the application in a healthy state.

Maintenance services are defined on an individual contract basis, as the maintenance phase can look very different from one project to the next. Our primary concern is that you love the final product delivered and that it continues to meet your needs and expectations.

Maintenance agreements require a minimum three-month commitment and can be purchased in 32 or 64-hour increments.

Our Code Process

Source Control

We use GitHub to host the source code for all of our projects. Github provides workflow features that are a core part of our development and design process. If you need your source code to be managed in-house, GitHub offers an Enterprise Edition.

Frameworks

Although we have opinions on which frameworks or libraries to use, we choose whatever technology best suits the job. Our developers build bulletproof web apps, APIs and mobile apps. For mobile apps, we develop cross-platform so that we can write one codebase that gives you both and iOS and an Android app for the price of one.

Development Workflow

We follow a standard branching workflow during development:

1. A developer creates a branch from the master branch that describes the feature. The branch name is auto-suggested by Clubhouse using their name, the corresponding ticket, and a short title. Example: jsjoeio/ch1962/convert-frontend-to-typescript
2. During development, the branch is periodically pushed to origin. When the code is complete with tests written to back up the change, the developer looks through the commit messages in the branch and makes sure that they are readable and understandable.
3. The developer creates a Pull Request on GitHub. Slack notifies the team. We require all Pull Requests to be reviewed and marked with a +1 by another team member. This marking indicates that the changes are ready to merge into the master branch.
4. When the Pull Request is opened, a CI (Continuous Integration) server runs the test suite, ensuring the entire test suite still passes. The CI server will automatically update the Pull Request with the pass/fail status of the test suite.
5. If a Pull Request has a +1 and passes CI, it is merged to the master branch by the developer who originally opened it.
6. The CI server will run the test suite a final time and automatically deploy to a staging server where it can be reviewed from the browser.
7. After a merge, developers should spot check the feature on the staging server so they can be sure everything works as intended in a production-like environment.

More on Continuous Integration

Testing automation from a CI server is vital to our process. Testing automation ensures our developers write proper tests, and it prevents changes to the app from “breaking” the test suite. The CI server is connected to Slack and notifies us if a Pull Request is ready to merge. Once merged, the CI server auto-deploys to staging. Circle CI is our preferred CI server because it’s easy to use, supports multiple languages and test suites, and is reasonably priced.

Release to Staging

We auto-deploy to a staging server so that it always reflects the master branch. This deploy serves as the final checkpoint before code is released to production.

Release to Production

We release code to production by either: (1) manually deploying through a script or git push; or (2) using the promote feature available on certain hosts. All of our developers can deploy to production and they typically do so multiple times per week.

Databases

Postgres is our database of choice. Postgres is proven, reliable, and modern.

Code Quality

We value code quality. Code that is easily readable and cleanly written is easier to maintain and update in the future.

We aim for about 80% of test coverage on projects. We’ve found that striving for a very high percentage offers diminishing returns and can cause developers to write bad or unnecessary tests. Instead, we rely on our developers to write enough tests to be confident that the project is sufficiently covered.

Testing

We write extensive unit tests and acceptance tests to ensure the integrity of each feature. In some situations, we write code first and write tests afterward. Tests are always written as they are critical to ensure that future features and iterations do not break existing functionality or business rules. We strive to write the right balance of tests because of the confidence they bring us.

Technology

We align ourselves with industry best practices when it comes to our tech. We choose solutions that are tried and true to ensure your app is of the highest quality.

Browser Support

By default, our team designs and develops code for modern browsers. If your application needs to support legacy browsers, we'll notate it in the statement of work and build in that time accordingly.

Monitoring

It’s important to track your application’s performance metrics. We use the metrics feature of your app's hosting platform to look at web response times, CPU, and memory usage. We use New Relic to detect and improve slow actions and queries.

Bug Tracking

We recommend Sentry for the real-time tracking of application bugs. We find Sentry works very well for a variety of environments and platforms, and it's cost-effective. We've got experience with all the major bug tracking platforms, so our team is happy to work with a tracker that you already have in place.

Hosting

We host static sites with Netlify and dynamic apps with Vercel. Ruby and Rails apps are hosted with Heroku. We are not sysadmins and find our time is better spent making applications awesome rather than configuring servers. If you need a recommendation for sysadmin work, we know some really great people that we can refer you to.

Project Management Tooling

As an agency, we have had the opportunity to test and experiment with numerous project management strategies. We've battle-tested almost every tool out there. When we say we can manage a project of any size, we truly mean it.

Our preferred software is Shortcut which features a robust Kanban board tool that integrates directly with Github as part of our development workflow. This tool is easy to grasp, user-friendly and doesn't require you to have GitHub access.

Shortcut holds the conversations around every single project feature, bug, and a chore. It's our realtime dashboard that helps provide several key measurements including:

• How much work remains
• How much work has been finished
• The velocity at which the team is completing work

We usually set up our boards in the following way:

• Backlog: All tickets start out in this column. We ask you to help write these and review and suggest any necessary changes to them.
• Upcoming Sprint: At Echobind, our sprints are usually one week long. Planning them efficiently is the key to success. During the current iteration, the next one is being planned and those tickets end up in this column. Incomplete items from the current iteration get moved here as well.
• Current Sprint: Each week a new iteration begins with tickets in this column as the focus. Every Monday the tickets are discussed and have estimates reassessed. While we do our absolute best to complete these within the week’s iteration, we cannot guarantee that all work will be finished.
• In Development: Once development or design work begins on “Current Sprint” tickets, they are moved to “In Development.”
• In Review: After they are completed, “In Development” features are moved to "Ready for Review" to be reviewed.
• QA: After undergoing code review and merged in, tickets are moved here to test that they meet success criteria.
• Completed: Items are marked as "Completed” once they are accepted.

Our Operating Process

Iterations and Hours

We work on client projects in weekly iterations (and charge that way). We typically work Monday through Friday (barring no major holidays or staff illness). We work during normal business hours and our team resides in all four major continental US time zones. We do not track the exact number of hours each employee works.

Invoicing and Payment

We require one week’s advance payment to begin a project. In successive working weeks, we invoice every Friday. Because we bill by the week, we do not itemize our invoices. We keep things simple for us and our clients and charge one amount per developer, per week.

Payment is due within 15 days of the invoice date. Invoices can be paid by check, wire transfer, or credit card (for a small fee).

Communication

We're a remote agency with team members all over the country. Working as a distributed team, we're versed in best practices when it comes to communication strategies.

Slack is our preferred chat system. Each project receives a private chat room that brings together our developers and project stakeholders. This chat room is used to deliver all of our communications. We try to use chat as much as possible so we can communicate frequently and informally.

We also use Slack integrations extensively to notify us when important events occur.

Example events include:

• Staging/production deployment notifications
• Bug notifications
• Source control commits
• Project management updates

Site reliability is something we take very seriously. The systems we put in place for each project ensure that team members are notified if any errors are reported. This ensures that your app is online 99.9% of the time.

Meetings

We don’t have a lot of meetings. Your budget is far better served when we’re actively working on a project. However, we do begin each project with a Roadmapping Session (as outlined above) which lasts between two hours and a full day. Once a week we hold a 30-minute recap meeting with you to discuss the iteration that was just completed. As a virtual office, we use Zoom for these meetings.

Sharing Files & Documents

If you have files, documents, or images, you can drop them into the Slack chat room for group sharing. This practice eliminates cumbersome, back-and-forth processes such as sending multiple emails to several people or adding individual accounts to Dropbox shared folders.