For the first year, Blackbyrds Digital was two people. That worked for a certain size of project. Then we started winning bigger builds and the math stopped adding up: two people, three concurrent clients, one shared deadline. We needed to hire.
We had never hired anyone before. We had no HR department, no established pipeline, no budget for a recruiter. What we had was a clear picture of what the work required and a willingness to run a deliberate process. Here is what that looked like.
Writing the Role Without a Template
We started by writing down everything we actually needed the person to do in the first ninety days. Not a wishlist of technologies. Actual work: build out the backend for a small CRUD application, participate in client calls, write tests for their own code, ask questions before going quiet on a problem.
From that list, we wrote the job post. It was short. Two paragraphs of context about the studio, a bulleted list of what the role involved, and a note about what we were not looking for - specifically, someone who needed hand-holding on basic development workflow.
We posted it on local Facebook developer groups and one job board. We got about forty responses in the first week. Most were filtered by a simple question we included in the application: describe a bug you found and how you tracked it down. Candidates who skipped that question or gave a one-line answer were not moved forward.
Screening Without a Formal Process
We did not have the infrastructure for a multi-stage technical interview. What we did instead was a short paid task - a half-day assignment with a small fee attached. The task was a real problem we had simplified: build a small feature on top of a provided codebase, write a README explaining your decisions, and submit it.
Paying for the task mattered. It signaled that we respected their time. It also filtered people who were not serious, because doing the task took effort and people who were half-committed did not bother.
From the submissions we received, we could see: how candidates organized their code, whether they read the brief carefully, how they explained their choices, and whether they asked clarifying questions before starting. The last one was the most predictive of how someone would perform on actual client work.
We interviewed three candidates and hired one.
Onboarding in a Small Studio
Onboarding in a two-person studio is different from onboarding at a company with an HR team and a structured training program. There is no training track. There is just the work.
We handled it by pairing closely for the first four weeks. Every significant piece of code the new hire wrote was reviewed and discussed, not just approved or rejected. We made time for those conversations even when the project timeline was tight, because skipping them would have cost more time later.
We wrote down the things we had never written down before: how we deploy, how we name branches, how we structure a project directory, how we communicate with clients in writing. None of it was complex. But it existed in our heads and needed to exist somewhere the new person could find it.
Four weeks in, they were contributing independently. Eight weeks in, they were running a small feature set on their own. That pace is what we calibrate against now when we hire: not how fast can someone start shipping, but are they asking the right questions after thirty days?
What We Would Do Differently
We took too long to make the decision. We had a clear first choice after the paid task stage and spent two more weeks second-guessing it. In a small studio, delay has a cost: the work piles up and the team absorbs it.
The paid task filter was the most useful thing we did. It is still in our hiring process.
If you are a small studio thinking about your first hire, the honest answer is: start with the work you need done in ninety days and write the job backward from there. Everything else follows from that.