We're designers and developers. We want to design and develop software. Before
we can do that, we need clients to hire us.
The overall process is:
- Someone contacts us via
our new project form,
phone, or email.
- We have a video call or meet in person.
- Qualify/disqualify: are we a good fit for the client?
- Qualify/disqualify: is the client a good fit for us?
- Understand the client's vision.
- Agree to the outcomes we're trying to achieve.
- Estimate iterations.
- Sign the contract.
- Pay us for the first iteration.
- Schedule people for iterations.
- We begin work.
Our leads often come from referrals from
We track each lead in Zendesk Sell.
We manually create Contacts for personal introductions. Our new project
form automatically creates leads for each
The Managing Director in the location will get notified about the incoming lead,
but anyone can take responsibility for it. The person responsible qualifies or
disqualifies the lead, often with a quick intro email, phone, or video call
with the potential client, before they move the lead forward in Sell, which
will change them to the owner.
We prefer to pair on sales calls, having at least one designer and one developer
on the call. This enables us to get multiple opinions on how good or bad of a
fit the client and project might be for us, it gives us the ability to answer
both design and development questions to the best of our ability, and it allows
us to train and improve our process during sales calls.
Understanding Product Vision
Our goal is to begin thinking about the client's product and working as a team
to plan it even before we officially start working together. Some example
questions to ask:
- What's unique about this product?
- What big benefit does the product provide?
- What pain does the product alleviate?
- Who currently buys this product?
- Who do you want to buy this product?
- What do customers love about your product?
We distribute the sales process throughout the team. Potential clients should
be able to talk to the people they'll work with. We should be able to handle
spikes in incoming leads that make it unreasonable for a Managing Director to
respond in a timely fashion.
We use an internal app to manage our schedule and availability. We don't track
time, but we do plan in week increments.
If the client asks us to sign an NDA, we respond with:
Are you willing to chat without signing an NDA? We've worked with hundreds of
clients. We talk to hundreds of potential clients each year. It's inevitable
that we hear similar ideas.
If the NDA is important to the client, ask them to tell us enough about the
business to evaluate whether there's a conflict with our existing or past
clients. If we determine there's no conflict, the project is a good fit, and the
NDA is mutual, we sign it. If their NDA is not mutual, we use our
No Fixed Bids
Some consulting relationships start with a requirements document or RFP
("Request For Proposal"). The requirements are often extremely detailed.
The probability of this document containing the optimum feature set is extremely
low. The right features are better learned through user interviews, prototyping,
releasing actual software, and getting feedback from real users.
Based on that document, clients expect consultants in the industry to submit an
exact timeframe and bid. This contract style sets the client and consultant
working against each other right from day one. Instead of focusing on designing
the product experience or evaluating what assumptions were wrong, they spend
time negotiating about what was meant in a document written a long time ago or
focusing on arbitrary deadlines. But it's worse than negotiating; it's
retroactively discussing something that no one remembers the same way.
As you might have guessed, we don't do fixed-bid, fixed-feature-set proposals.
We do need to know clients'
budgets. This is often
uncomfortable for them but their budget helps determines what scope is possible.
It saves time. If they don't know their budget, we discuss different options.
We talk about breaking product rollout into stages and try to improve the
product's chances of success at each stage by:
- Focusing on a small subset of features.
- Designing a valuable user experience.
- Developing a meaningful relationship with users.
- Budgeting for marketing tactics to tell users about the product.
- Designing interactions into the product for users to bring other users to the
We price projects at a per person, per week rate. We consult 4 days per week. We
use the same rate for designers and developers. The work required for each week
dictates which skills are needed. The number of people needed determines the
cost and how much gets done.
During the process of explaining our billing, we sometimes tell potential
clients "time and materials" is the same as hiring an employee for their annual
time except there's less risk to them because:
- Our team is experienced. We've interviewed more than a thousand candidates in
order to find the talented group of people we work with today.
- We've worked together on projects before. We have "a way" of doing things.
- Short projects require less money.
- Our time is predictable (4 days/week) and consistent.
- We can quickly rotate in a new team member if someone gets sick, leaves the
company, or is ready to rotate to a new project.
We don't provide itemized invoices to clients showing individual pieces of work
that were done. Clients always know what is happening via access to the project
management system (Trello), chat room (Slack), version control system
(GitHub), and ongoing communication with our teammates.
Examples of typical projects for us are:
- "Product design sprint", 2 people, 1 week
- "Idea to Version 1", 3 people, 8-12 weeks
- "Fill a gap until an internal team is hired", 2 people, 3 months
- "Staff augmentation with existing internal team", 3 people, 6 months
On many occasions we've done projects for clients who have a budget enough for a
"Version 1" product. They followed that up with a round of beta invites, time
spent learning in the market, a round of funding, or a few months of revenue.
They come back for another round of design and development with a more informed
sense of where the product needs to go.
The feature set of a product is not necessarily indicative of the length of time
required to develop it. Sometimes to get to a very simple product, we have to
iterate on it many times. We love working with clients who understand that a
great product takes as long as it takes.
In return, we understand that we can never abuse a client's trust in us. We
should be maximizing our productivity in order to provide them the most value
for our time. Things like our "Research" Trello board,
"Code" internal chat room, and shared
dotfiles ensure we have a highest
common denominator set of tools and techniques ready when the situation arises
We store contracts in Dropbox and have a series of folders for pending, current,
past, and lost clients.
The consulting proposal and contract contains:
- A one-page summary of the expected work.
- Our weekly rate.
- Net 15 payment terms.
- Payment for the first two weeks is required to start working.
- After the first two weeks, invoices will go out once a week on Saturday
mornings for the prior week's work.
- Agreement that the client owns the week's source code once they've paid their
- Agreement that both parties won't use materials which break someone else's
- Agreement that both parties won't publish things to the web hosting provider
which are abusive or unethical.
- Agreement that the contract is mutually "at-will" and either side can decide
to stop work at the end of a week.
- A page for signatures.
We use Quickbooks and Bill.com
to invoice our clients at the end of each week.
Clients can pay their invoice via check, ACH, or wire transfer.