Code constructed with care

Ways we can work together get your product built

During the technical audit a Def Method engineer will work with you to answer any technical questions you have. For example they can focus on an assessment of the health of your current code base, they can work on building an estimate for new features you are looking to build, or they can offer general technical guidance. Also, it's free : )
Our NYC-based engineers will work on site with your team. By having our engineers in the office, you can experience information osmosis. In this, we mean that development can be more productive when the engineers understand the industry and overall company goals and your team will benefit from a better understanding of the technology.
We teach through example. When you work with Def Method engineers they not only will move your product forward, but they will also work with your team to make strides with overall resource efficiency. This can be done through pair programming, implementation of agile process such as daily standups, or overall engineer management.


We're a language-agnostic team of engineers who choose a particular language because of its appropriateness for a particular project (taking into consideration language ecosystem, performance, etc.), and not purely because of the skill-set available within our development team. We're excited to learn new languages to help implement our projects in the best possible way.


Continuous Integration & Multiple Environments

The Use of Continuous Integration and Multiple Environments

Every time our engineers make a substantive change, they will commit this change to GitHub (or other hosting service of your choice). Def Method employs an automated continuous delivery process whereby any changes in GitHub are detected. Once a change is detected, all unit tests are run. If they fail, all developers are notified immediately so that a fix can be made. If all tests pass, the continuous delivery system will deploy these new changes directly to the staging environment.

Def Method maintains two environments when building applications: a staging and a production environment. Production is what you might expect: it’s the live site, the public-facing application that everyone uses on a daily basis. The staging environment is not open to the public. Our customer and Def Method engineers are the only ones who can see the staging environment. With a staging environment, stakeholders can see our progress, evaluate features, and experiment without worrying about impacting real users. We also benefit from seeing features run on an identical ecosystem as production. This increases the efficiency of delivering features and reduces the risk of introducing bugs into the production system.

Jeff Jia, in "What is Continuous Integration?"
Principal Engineer

Test Driven

The Importance of Test Driven Development (TDD)

At Def Method we have several core values that we insist on when working with a client. Once of those core values is the use of test-driven development. Test Driven Development or TDD, for short, is a software development process that builds up a suite of automated tests alongside our software. These tests run continuously to ensure proper functionality and to reduce the presence of bugs. In our opinion, testing is paramount for the future success of your project. Since we partner with each of our clients, your future success is a main priority. See more on our philosophy on test-first in the article below.

Paul Ort, in "Test-First Programming for Improved Software"
Principal Engineer

Healthy Dependencies

We strive to always practice sound decision making in the writing and maintenance of code.

In almost any software engineering project you will find the use of third-party libraries/dependencies. While the practice of using third-party libraries can help to speed up the velocity of development in the short term, it's important to be mindful of the code being added to your project so that it doesn't have adverse effects in the long-term. In this article, Principal Engineer Paul Ort explores the topic of code reuse in the delivery of value. To learn more about this topic or connect with Paul, please contact us via the form below.

Paul Ort, in "Healthy Dependencies"
Principal Engineer

Find out more about how we work

Product Management

Let's partner together

Need an NDA?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.