Why your tech stack should remain a mystery (in an RFP)
One of the critical tasks of managing any project is bridging the gap between the stakeholder who oversees the software product, and the developer who oversees the implementation. The responsibilities that come with these roles are largely mutually exclusive, making it hard for a stakeholder to know what’s feasible with their timeline and budget, as the technical work necessitated by their vision is largely unknown to them. Likewise, a developer without domain knowledge specific to the project may find it challenging to understand the stakeholder’s intuition about which features are critical, how they should be prioritized, and what business constraints should inform the implementation.
Luckily, LLMs have eased some of this difficulty by serving as a competent intermediary between the two. With a well-formed query, a stakeholder can describe the scope and constraints to an LLM and receive a reasonable description of an effective tech stack that could serve the project. Then the stakeholder is able to publish their RFP with a reasonably-informed description of the requirements of the project.
Unfortunately, some stakeholders take this a step too far by including the LLM’s suggested tech stack in their RFP. This does make it clear to developers what skills could be needed for the project, but has some unintended side-effects that can negatively affect the process:
- Developers who could do the job with equivalent technology are discouraged from responding. By listing specific brands of technologies (including languages), an RFP can unintentionally filter out a large number of capable developers who happen to have proficiency with different but equivalent brands. Unless your project is built on legacy software with technology you’re locked into, it pays to use generic descriptions of the technologies you plan to use. For example, instead of listing the LLM’s suggestion of Supabase as a required technology, use the generic description of “relational database”. Developers who are experienced with PostgreSQL may not feel it’s worth spending the time to explain that Supabase is a PostgreSQL provider and that their skills would easily transfer.
- Rough drafts turn into final drafts over time. Initial ideas are inertial ideas, meaning they slowly gain momentum and crowd out any equivalent options. When specifications of the tech stack are suggested as placeholders, they’re rarely replaced, making them permanent over time. By leaving the elements of the tech stack as generic as possible, some thought will be required to determine which options to go with. Thought that the developer building the project can make, with the benefit of their experience.
- Ultimately, the developer will know best. The LLM has no skin in the game, and its motivations for choosing the tech stack that it does are probably unknowable. The developer who will be building the project, however, does have skin in the game and their motivations are obvious: to provide a software product that satisfies requirements within the scope of time and budget. Trusting the LLM to decide the tech stack may be savvy, and the LLM may even do a better job of choosing than most developers could. But a project is more likely to be successful when the developer has a sense of ownership over the decisions within their scope of duties.
By keeping the elements of the tech stack generic, avoiding placeholder decisions, and allowing the developer to determine which specific tools should be on the stack, it will be easier to find experienced talent who can ensure an effective design.