Hire a person or buy a build
Stackologists treats a hire as a person in your stand-up and a build as a result on a date. Mixing the two into one vague retainer is how both go wrong.
Clients often ask for “a senior full-stack person” when they need a finished API, or they ask for “a project” when they already have a team and a backlog. The wrong contract wastes a quarter. The right one is usually obvious once you name who owns the outcome.
Hire when the work is ongoing
Staffing is the right call when you already have a backlog, a stand-up, and someone who can review work. You need capacity inside a system that will still be yours after the engagement. The Stackologist joins that system. You keep the product.
That only works if the stack list is real. If the posting names six frameworks and the increment will touch two, we match against the two. Otherwise you are staffing a fiction.
Buy a build when you need a finished piece
A build is the right call when the useful outcome is a finished piece: an admin that replaces a spreadsheet, an API other teams can version against, a public site that search can read. We own the result for a bounded window. You do not need another person in Slack. You need the thing to exist.
We write the stack down before kickoff and demo every week. Handoff includes the decisions, not only the repository. If you later want that person on your team, that is a new conversation — not a silent conversion of a project into a seat.
What has to be true next
Say that sentence out loud. If the answer is “we have a named person shipping in our process,” that is staffing. If the answer is “this form, this API, or this site works,” that is a build. If the answer is “search can finally see the product we already shipped,” that is technical SEO.
We will pick one. A single conversation can change the pick. It should not try to be all three.