Founded in 2013, we’re a team of designers, engineers, and strategists who build software applications to help the planet’s most promising health 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 on building healthcare products based on lessons learned from designing and developing dozens of web and mobile applications.
Before we dive in, remember this is a living document. As our company grows, our playbook will evolve.
Building is intoxicating. The opportunities to innovate and improve our tech-enabled world are limitless and immediately impactful.
And in our opinion, the most important technological advancements ahead of us lie in making healthcare more accessible through software products and digital health.
As we not-so-subtly point out, healthcare technology is dated. The problem is that most clinicians and healthcare experts don't know the first thing about building software. Conversely, most tech startup teams don't have experience navigating the complexity and nuances of building products for health.
Our company exists to bridge this gap. No other team is as focused or experienced in building software for the various healthcare personas.
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.
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 four types of work that spearhead all software initiatives.
We don’t just build software products though. 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 VC or PE 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.
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.
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.
The most critical phase of any software product happens before you write a single line of code.
We begin building products 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.
Often, we’ll lead clients through a Discovery and Product Sprint to help define the problem space and pressure test assumptions to understand if their idea is... well… good.
For clients with established product market fit (or hints of it), these Sprints allow us to discuss your product vision, review existing assets such as user research, designs, or code, and create a Product Roadmap that outlines the what, how, and why of building your product.
We’ll gather requirements, ruthlessly cut and prioritize features, assess technology and vendor choices, and detail the order of operations needed to build your product.
Our Discovery and Product processes will give you the confidence that:
People don’t just buy from companies—they buy because they feel a connection to the brand. A brand is more than logos and colors and icons. It’s a company’s DNA. When done right, a company’s brand will tell you where they came from, where they are headed, and what purpose drives them forward.
A brand identity humanizes a business and differentiates itself from the competition. If done well, it can even eliminate the competition entirely, because no other company’s brand can compare.
Our process for branding might be the same for each client, but each client’s brand is unique. We study their audience, develop the brand’s foundation, and cultivate the unique visual and written elements that comprise their identity.
Whether as a startup looking to make a lasting first impression or a Fortune 50 company in desperate need of a refreshed look and feel, it’s critical to design how you show up in the world.
Especially in healthcare, a brand needs to be trustworthy, thoughtful, and memorable.
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.
UX and UI Design is more than just visuals that communicate your product idea. They’re the expression of your product’s value.
Design is a process to help:
UX and UI designs must balance user desires with business goals, what is technologically feasible with what is financially viable. They define your features and user personas and help you discover the boundaries of what is and is not your product.
There is no “one-size-fits-all” user experience.
Our design approach depends on your product's industry, differentiation from competitors, and the personality of your brand. For all projects, our designers present a variety of design concepts based on user research. We may create one that is a conservative approach, one more vibrant, and one in between. 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 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.
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 being 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.
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.
Our team understands that the way you deliver work is just as important as the quality of the output. We execute reliably and proactively address issues.
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 9 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 per 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-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 around 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.