Founded in 2013, we’re a team of designers, engineers, and strategists who build software applications to help the planet’s most promising startups and companies improve the lives of their patients.
Our team is global. But we're forever New York.
Our Playbook is an in-depth look at who we are and how we operate our business. We share our process and beliefs based on lessons learned from designing and developing hundreds of web and mobile applications.
Before we dive in, remember this is a living document. As our company grows, our playbook will evolve.
Why We Build
Building is intoxicating. The opportunities to innovate and improve our tech-enabled world are limitless and immediately impactful. Yet, our founders’ early experience of building software for others was inefficient and frustrating.
Startups with inspiring entrepreneurs and genuinely great ideas were making poor decisions and failing miserably. Ones that did succeed after finding product market fit couldn't hire quickly enough to scale. Enterprise companies with talented employees were too inundated with processes and structural BS to actually make meaningful changes.
Our company was founded to fix these problems. Speed and quality of work are not mutually exclusive.
There’s a reason our company has steadily grown over the past seven years based on repeat and referral business alone - execution and authenticity. We only build solutions we believe in. Each client receives the leadership of our founders and complete transparency into our process. We thoughtfully challenge decisions to help you create not just a great product, but the right product.
We're also realistic. Contrary to popular belief, designing and developing successful software is not about secrets, hacks, or shortcuts. It's also not measured by hours of time invested. Rather, it’s measured by iterations. You can plan software projects all you want, but you need to actually build, launch, and learn from them.
Because of this, we have high expectations for our teams and also for our clients. We operate with a bias to action, continuous feedback, and an emotional investment in each client's success.
How We Can Help
Health companies, ranging from up-and-coming startups to Fortune 1000 behemoths, hire us to build their software and digital products. To do that, many individual steps, skills, and deliverables need to align. Our team specializes in three types of work that we find spearhead all software initiatives.
- Discovery and Scoping - Intensive software planning through technology research and product validation in target markets.
- Design - Creating user-centric designs and brands with thoughtfully crafted UX and UI.
- Development - Inheriting software or building robust web and mobile applications from scratch through a well-tested, tried-and-true process.
We don’t just build software products. We build companies, teams, and people, too.
For many of our clients, we vet engineers and designers, advise on strategic initiatives, and introduce teams to capital.
We understand that all great products begin with people banding together and that human relationships drive these interactions and decisions.
If you’re a Venture Capital or Private Equity firm, we provide technical evaluations for your portfolio companies, interview possible engineering candidates, and act as a technical sounding board for upcoming projects in exchange for referrals and introductions to new founders and companies.
How We Work
We believe in hiring the best talent. Sometimes that's in Brooklyn. Other times, that's across the globe.
However, we don’t “off-shore”. We never play the "middleman". We’re directly involved in (and responsible for) the planning, execution, and success of every project we take on.
Currently, we work 100% remote (for obvious reasons).
We do our best work with entrepreneurial, adaptable, and open-minded people and companies that are committed to building something great in health. Or at the very least, something better.
We charge for our time by the day, week, or month. We never bill hourly. You're not paying us to be timekeepers - you're paying us to do great work.
As of late, we create digital products for companies specifically within the health, wellness, and HCIT space (but we’ve been known to make an exception every now and again if you’re doing something interesting and ambitious).
We’re comfortable working on projects that require security clearances and background checks as well as ones that are open source and free to use.
For each of our projects, we hand-select an experienced combination of designers, engineers, and product owners from our team to complete the work.
We’re also not opposed to working alongside your own team in a staff augmentation model, especially if you already have product market fit, are growing quickly, and feel comfortable owning the product direction and project management. We understand starting a company and building a product is messy, so we make working with our team flexible.
While certain projects may be large with their goals, we like working on small teams within them. We believe in pair programming, where multiple engineers collaborate to write and review code together. We also like to pair on design, QA, and all other phases of the software development process. Given enough eyes, all bugs are shallow.
For each project, we’ll assemble a product roadmap and work in Sprints (this is simply a two-week timeframe for teams to group work) to make progress. Without them, tasks and goals tend to spill into one another, and it becomes difficult to assess where work begins and ends.
Developing a great product is both a process-driven (checklists, peer-review, in-person collaboration) and a creative (my headphones are on...don't talk to me) endeavor. Achieving flow state is important, and we empower our team with the time and flexibility to work without distractions.
We deeply value our meeting time together, keeping them structured and efficient while allowing for creative discussion and serendipitous ideas. In each client meeting, we review and demo our past work, discuss any blockers, and plan out the next Sprint to assign work.
Internally, we meet each day to review our client work. With clients, we meet weekly to review output and continuously iterate on feedback. We can’t emphasize enough how important it is to have our clients involved and participating in the feedback process every week. Our team’s value is not just the work we create, but also the habits we practice and teach.
Whether scoping, designing, or developing software, we're not dogmatic about the ways we can work together. We’re familiar with Agile, Kanban, Scrum, and other flavors of project management, and we don’t only chase the latest programming languages or frameworks. We're conscious of what really matters when writing high quality software –– tests, documentation, communication between design and development teams, and our clients.
Our Design Philosophy
Great product experiences are rooted in design. No matter how fast, how clean, or how well-structured the code is, users won’t engage with a product that is not intuitive and memorable.
Because of this, we begin all creative design projects by ensuring we’ve identified the problems a product will solve and asking why this product, and why now?
Exceptional clients come to us with some form of product validation demonstrating this, both with anecdotal and quantifiable evidence.
We don’t like working off “hunches” as the barriers to test and prototype ideas are incredibly low.
With many clients, we help build microsites and splash pages, surveys, and temporary product pages that can help teams understand if their idea is... well… good.
After establishing product market fit (or hints of it), we begin designing the product.
For all projects, our designers present a variety of different design concepts based on user research. We may create one that is a conservative approach, one more vibrant, and one likely in between. Our design approach depends on your product's industry, differentiation from competitors, and the personality of your brand. After reviewing with the client, we’ll narrow the direction, combine feedback, and further iterate the designs.
For each application we design and build, we create Site Maps to identify all workflows and Information Architecture diagrams to establish an application’s vocabulary and hierarchy. We annotate our wireframes and high-fidelity designs for each action a user can take on each view. We remember to design for different views too, such as for error, empty, default, loading states, and transitions between views. With design, the devil is in the details.
How much or how little we invest in design depends on each product’s goals. While some clients are comfortable building prototypes without significant UI design, others desire something more polished for their target users. Generally, proper design will amplify a product’s success. In some cases, though, it doesn’t (we assume you’ve seen CraigsList).
Regardless, it’s more important to first understand a problem and gain traction than it is to design a beautiful product.
Our Development Philosophy
We don’t just care about the quality of our software, but the process too.
Our development work begins at the data model layer. By understanding the relationship of data as objects within the application, we assemble an accurate hierarchy of information.
From here, we balance both view layer and frontend code as we develop. Depending on the tools used (programming languages and frameworks) and the type of app architecture (e.g. monolith vs. microservices, Single Page vs. CRUD), we adjust our development style to fit the goals of each project.
If building a simple marketing website using a CMS, we need a less robust software development process and a heavier emphasis on frontend implementation and polish.
If engaging in a multi-month application build or legacy transformation, we’ll need to focus more on software process, app architecture, scoping, and other technical considerations.
Software development is a balance of what needs to be done now? with what can be done later?
We encourage our clients and team to understand that software needs to not just be developed but also maintained. Good engineers know there is no such thing as “write once and it works forever.” Updated third party libraries can break code. Cloud-based services can crash. Critical bugs can even exist in common software programs for years before discovered and resolved (see Heartbleed). Maintaining software costs time, attention, and money. It’s just as important to refactor code as it is to develop revenue-driving features.
Our best clients are eager to learn about the design and development process, known as SDLC (Software Development Life Cycle). We love teaching it and seeing clients continue our habits months and even years later.
We write tests for all our code: Unit Tests, Integration Tests, UAT, and others. When developing within an established startup or enterprise company, no amount of tests can be enough.
That being said, we don’t allow over-testing to get in the way of “shipping”. If you’re building an MVP, you don’t need a full test-suite. You need to launch your product as soon as possible.
When merging and deploying code, we’re meticulous. We use tools like Gitflow for branching, and we monitor test coverage before shipping anything to production. The code we write is hosted using a mix of cloud providers, which is often specific to each project and each client.
Although we have our favorites, we are indifferent to any particular tech stack and are happy to work with specific tools if requested.
Our Core Behaviors
In many companies, values are used to drive culture. We believe behaviors is a more appropriate word since values, if not acted on, are meaningless.
Andrew Bosworth once wrote...
"Being kind isn’t the same as being nice. It isn’t about superficial praise. It doesn’t mean dulling your opinions. And it shouldn’t diminish the passion with which you present them. Being kind is fundamentally about taking responsibility for your impact on the people around you. It requires you to be mindful of their feelings and considerate of the way your presence affects them."
We agree with Bosworth.
We keep our communication clear, frequent, and honest; we seek to understand before being understood.
We create an environment where open-mindedness is practiced daily, where people are encouraged to express their opinions while being prepared to have them challenged by others.
No single team member makes or breaks our team. But, every one of our team members is expected to be aware of their strengths and weaknesses and to view mistakes as an opportunity to learn or to teach.
How do you price your services?
We use a mix of Time and Materials and Value-Based pricing. For projects with a narrow scope, we will sometimes offer a Fixed Cost.
Service companies can be three things: cheap, fast, or good (seriously, you can google it). But, they can only be two of these three things. Be wary of any team that tries to claim they are all three.
Polite warning: we strive for fast and good. So, we aren’t cheap.
How do you estimate software timelines?
We use Evidence Based Scheduling (comparing your application to similar past projects) whilst minding the Cone of Uncertainty (carefully estimating software development time only after designs and technology research are completed). With a dataset of 150+ projects from our 8 years of being in business, we’re pretty confident in our ability to accurately estimate projects.
Unlike other agencies, we always present a conservative quote to avoid future surprises - as in, our quotes are the max costs to expect if working with us. We won’t try to sell you on lower costs and then price gouge mid-project as scope changes (because it always does to some extent).
Do you accept equity in exchange for work?
We do, but rarely. We usually only take equity in one company a year, and it’s after working with that startup client for ~6 months prior to that. It’s also always a cash and equity split, versus just equity in exchange for our services. When taking equity, we ask for what most seed stage investors or accelerator programs take.
Do you work on-site with clients?
Once upon a time, and we hope to one day do it again when this mess is behind us.
Will you sign an NDA before meeting?
Like a VC firm we meet with a lot of folks, so we don’t sign NDAs. However, we make exceptions for enterprise companies, government entities, or startups with serious amounts of IP. If you have just an idea or a prototype but with no users or traction, it doesn’t make sense to sign an NDA.
Do you take legal ownership of the software you write for us?
We don’t “own” any of the work we build for you. You do. That’s why you’re paying us. Be wary of development firms that say otherwise.
What happens when we’re done with the project? How do you transition the work to us?
Creating an “end game” plan is part of every client project. When a project ends, we usually transition all of our work to our client over a period of 1 to 2 weeks. We make sure they have access to all of the assets we created like designs, documents, or code.
Many clients have their own internal engineers who work with us to do this. But if not, we can stick on and keep working on a monthly retainer after or even start a new project with the same client.
How soon can you start?
It takes 2-3 weeks after signing a contract and receiving a project deposit to kick off actual work together. During that phase, we’re reviewing any materials you’ve already created like user stories, wireframes, or product roadmaps or assessing the quality of inherited code.