Rethinking the 'No Consulting' Mandate for Startups

Kin Lane, an expert in the tech landscape, offers a compelling counter-argument to the common advice that startups should avoid consulting.

A recurring piece of advice from investors and advisors in the technology sector cautions startups against engaging in consulting. While early sales are often encouraged, consulting is consistently presented as an unfavorable path. This sentiment is not new; it was a constant theme during my tenure as API Evangelist and a recurring challenge I faced as Chief Evangelist at Postman. Having long understood and questioned the rationale behind this perspective, I aim to delve deeper into the topic. My goal is to build a new argument for the value of actively guiding customers, even while navigating my own path, and to advocate for fair compensation for the effort involved.

Educating Customers

I recall Sam Ramji, after interviewing me around 2015—following Apigee's IPO and subsequent acquisition by Google—thanking me for my API Evangelist storytelling. He explained that Apigee, as a startup, leveraged my stories to help educate their customers. He added that they were prohibited from consulting or heavily investing in the essential education, workshops, and consulting their customers required, as their board did not prioritize it. This was a consistent narrative from numerous startups during my time as API Evangelist, with only a handful ever sponsoring or supporting my work. I eventually became accustomed to the often transactional and unsupportive nature of the API ecosystem.

Chief Evangelists

Between 2010 and 2019, API Evangelist played a pivotal, general role for the API industry, fostering education about the production and consumption of HTTP APIs. I translated this role into my position as Chief Evangelist at Postman, where I served as the enterprise face of the platform for existing and prospective customers. This role, seen across various technology companies, focuses on educating and guiding customers in their areas of need. Evangelists leverage expertise, primarily through stories and strategic guidance, assisting companies, organizations, institutions, and government agencies in navigating the digital technology landscape.

Developer Relations

Debates abound regarding the distinctions between an evangelist, a developer advocate, or a developer relations (DevRel) specialist. I perceive evangelists as operating more broadly, often communicating from a top-down strategic perspective, whereas DevRel focuses on precise, bottom-up engagement. A robust developer relations function is crucial for any product-led strategy, as it educates and engages with developers "in the trenches." DevRel provides the stories, artifacts, and tools necessary for developers' success. Through workshops and training, developer relations delivers essential hands-on knowledge to propel businesses forward, frequently bridging the gap left by companies that neglect proper investment in developer education and training, while also focusing on how products and services are adopted and utilized across operations.

Sales Engineers

Sales engineers bridge the gap between sales and technical expertise. Their responsibilities include explaining complex products to customers, preparing and delivering technical presentations, and providing sales support. They collaborate with sales teams to understand customer needs, identify pain points, and ensure proposed solutions meet the client’s technical and business requirements. As a Chief Evangelist and Head of DevRel, it is vital that this work aligns with the narratives being shared, and that feedback and insights from these conversations are integrated into the overall product roadmap, go-to-market strategy, and ongoing customer engagement. This early insight from the sales cycle should inform all subsequent strategic decisions.

Solutions Architects

Solutions architects design and supervise the implementation of technical solutions, translating business requirements into technical blueprints. They collaborate with stakeholders to define project scope, evaluate technology options, and ensure the final solution is secure, scalable, and meets objectives. They communicate complex technical details to both technical and non-technical audiences and manage project progress. The key distinction here is that solutions architects operate post-sales, while sales engineers work pre-sales; however, strong synergy between these roles is essential. As previously stated, insights from this work should inform other business functions. This is where my questioning begins, as most investors advise investing in solutions architects but not in professional services and consulting, often without clear guidance on the differences or justifications.

Professional Services

Professional services within a company encompass expert-based, knowledge-driven, non-physical services that support businesses in operating, growing, and improving. They are delivered by firms or individuals with specialized skills, rather than through the sale of a physical product. This area often represents a gray zone for startups. Some companies establish professional services groups, but many do not. While we've seen companies like OpenAI fully embrace this, the nuances distinguishing sales engineers, solutions architects, and professional services are rarely articulated by those advising against extensive involvement in this work. I consistently advocated for a professional services group at Postman throughout my tenure, losing the battle each time I pressed for it. My primary motivation was to scale my own impact, yet I was repeatedly told it was a "quagmire," despite being flown globally to perform precisely this kind of work.

Value-Added Resellers (VARs)

In the IT channel, Value-Added Resellers (VARs) are organizations that enhance the value of third-party products—such as original technology from vendors—through activities and services like installation, providing additional hardware, consultation, integration, product support, and troubleshooting. This is an area that startups should actively cultivate and build relationships with over time. VARs offer a significant entry point into enterprises, though, regrettably, I often find them not fully updated on the latest API practices. They tend to focus on more entrenched software solutions and don't always represent the long tail of SaaS that I work with companies to implement systematically.

Systems Integrators (SIs)

A Systems Integrator (SI) plays a role similar to a VAR, combining hardware and software from vendors, with the key difference being that many SI solutions are new and custom-built for a specific end-user. When it comes to stitching together numerous SaaS or open-source solutions, this represents an important investment area for a company. How your software and the software you build upon work in concert is crucial, and having a trusted external organization or group of organizations available to perform this work is a key component of any startup strategy. I believe this reflects the future direction of the entire VAR space, continually shaped by APIs and open source.

Managed Service Providers (MSPs)

Managed Service Providers (MSPs) are another category whose principle is embedded in their name. An MSP is an organization that delivers outsourced services in conjunction with the hardware and software solution provided to an end-user. MSPs adopt a more "white-glove" and high-touch approach to managing software in use, offering an excellent way to offload specialized expertise to another company. I anticipate that MSPs specializing in open-source and sovereign solutions will increasingly emerge as a vital selling point for large global enterprises operating in specific markets. Alongside these managed services, companies gain much of the expertise often lacking in the average enterprise.

Independent Software Vendors (ISVs)

Independent Software Vendors (ISVs) are often able to consolidate specialized areas of the martech stack, offering customers options to fulfill their software requirements. Major hardware vendors frequently support ISVs by rewarding software vendors that produce high-quality, compatible programs with valuable certifications. I need to conduct further research into how ISVs operate to better understand their overlap with APIs and SaaS. I also don't fully grasp the distinction between MSPs and ISVs, but this exploration is precisely why I am writing this—to map out the landscape and then delve deeper into how things function today, and how they will evolve as cloud, SaaS, and AI continue to reshape our environment.

Consultants

Here, we approach what I believe those advising against "consulting" are truly referencing. Your typical enterprise likely engages with management, strategy, IT, digital transformation, cybersecurity, data analytics, business process, financial, human resources, organizational change, operations, supply chain, marketing, sales, compliance, risk management, merger and acquisition, tax, legal, environmental, sustainability, real estate, executive search, training, development, and quality assurance consultants. My question is: how does this map to SaaS, and how does it overlap with evangelists, DevRel, sales engineers, solutions architects, professional services, VARs, SIs, MSPs, and ISVs? I am not advocating for open-ended consulting arrangements with our customers. Instead, I will need a strategy that encompasses all these areas to clearly define what constitutes "consulting" or "professional services" and to push back effectively against those who tell me not to invest in this crucial area.

Domain Experts

I want to integrate the ecosystem aspect of what Naftiko is developing. We have an open-source core that encompasses not just standards and tooling, but also domain experts. The ecosystem surrounding open-source standards and tooling is rich with knowledgeable domain experts. Companies tap into this expertise daily, yet, similar to open-source standards and tooling, this value is often unacknowledged and unaccounted for. The knowledge, practices, and processes of these domain experts are integral to every player I've listed above, and significantly, this is an area I am not told to avoid. I should absolutely leverage the time and energy of these domain experts. The contention, however, often lies in not paying them—which brings me back to what Sam Ramji of Apigee and others have conveyed. This is precisely why I'm dissecting this discussion: open source and open ecosystems are at the heart of why we are often told not to engage in consulting. I intend to explore this more thoroughly in 2026.

Pundits

It would be remiss not to mention the multitude of pundits advising people on what to do. These range from genuine analysts who possess deep expertise to transient "snake oil salesmen" who promote their narratives at conferences and via social media. Most enterprises glean their information from this layer. In workplaces lacking significant investment in education, training, and skills development, there is a substantial appetite for the information this class of pundit disseminates. While I often criticize this layer, I honestly place API Evangelist within this category. I am primarily a storyteller, yet I believe my stories to be truer and healthier. I've learned during this AI era that many others feel the same about their work, despite evidence to the contrary. However, if enterprises are listening to these stories, I must consider pundits a part of this landscape.

Guiding Naftiko Customers

This brings me to the core reason for this post. I am resolute in my commitment to guide Naftiko customers in all the ways I have as API Evangelist and Chief Evangelist at Postman. I am determined to win my arguments with investors, advisors, and others who deem selling "consulting" services a poor idea. I seek to gather evidence to educate and defend my approach. Furthermore, I intend to open source my methodology. My aim is to challenge those who gatekeep and police the knowledge and practices prevalent in this domain. I want domain experts to earn the compensation they need to thrive. I want to empower ground-floor employees within enterprises with the knowledge, practices, standards, and tooling necessary for success, even if their leadership is reluctant to properly invest in these areas.

I am not embarking on the development of Naftiko's marketing, sales, developer relations, sales engineering, and solutions architecting without a comprehensive plan. I intend to cultivate my understanding and relationships with VARs, SIs, MSPs, and ISVs. I will continue my historical collaborations with firms like EY, Deloitte, and others, as well as with Gartner, G2, and other analysts. I will continue to engage with my "snake oil brothers" at conferences and along the information superhighway. I will strive to convince more investors to support open source and the domain experts across every industry. I am determined to tap into the signals emanating from companies, organizations, institutions, and government agencies, while simultaneously incentivizing individuals within them to share insights about their activities and needs. I am uncertain what I will ultimately call this multifaceted effort at Naftiko, but it will span all the areas I have listed.

A couple of crucial insights I've gained: I believe many stakeholders fail to consider the entire landscape of how startups both acquire and provide what's needed from and to their customers. Instead, they are captivated by narratives of "scale at all costs," only to be confounded when scaling stalls at a certain point. Without robust feedback loops across these diverse areas, progress becomes stagnant. We have heard the narrative that "consulting is bad" so often over the years that we re-tell it without much consideration for the overall landscape, particularly within the context of distributed open-source systems. While there are certainly times when I should not engage in hourly paid consulting, there are equally many instances where it profoundly benefits both parties involved. Ultimately, the lesson for me is to discern when and when not to consult, while also being transparent about what we derive from and contribute to the open ecosystem along the way.