--- published: true layout: post title: As a Startup You Should Not Be Consulting date: 2025-10-23T09:00:00.000Z tags: - Consulting - Professional Services - Evanglism - Developmer Relations - Sales Engineers - Solution Architects - Value-Added Resellers - Systems Integrators - Managed Service Providers - Independent Software Vendors - Consultants image: https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/bf-skinner-fixing-satellite-2.jpeg --- A common refrain you hear from investors and advisors as you navigate the technology landscape is that it's a bad idea to do consulting. I also hear that you should be selling as early as possible, but you should by no means be doing consulting. This isn't new. It's something I heard from folks throughout my time as API Evangelist, and it's a battle I repeatedly lost at Postman as the Chief Evangelist. I've long understood the belief system behind it and have challenged it, but I wanted to think through it some more as I work to mount a new defense on the subject of helping your customers find their way while I also find my way, charging for the time and energy spent doing the work along the way. #### Educating Customers I remember Sam Ramji telling me after he interviewed me in 2015 or so, after Apigee had gone public and then been acquired by Google, thank you for my API Evangelist storytelling. He said that as a startup they were able to refer to my stories with their customers to help educate them. He added that they weren't allowed to consult or heavily invest in the education, workshops, and consulting that their customers needed because their board wouldn't prioritize it. I heard this from startup after startup during my time as API Evangelist, with only a handful of these startups ever sponsoring and supporting my work. I eventually got used to what a transactional and non-supportive space the API realm can be. #### Chief Evangelists API Evangelist played a more general role for the API industry between 2010 and 2019—helping educate everyone around what was going on with producing and consuming HTTP APIs. I translated this role into my time as Chief Evangelist at Postman, where I was the enterprise face of the platform with our customers and would-be customers. This is a role you see emerge at many different types of technology companies, but it's one that continues to educate and guide customers in whatever area they need. Evangelists deal in expertise, but mostly in stories and strategy guidance, helping companies, organizations, institutions, and government agencies find their way in the world of digital technology. #### Developer Relations There are plenty of debates around what the difference is between an evangelist and a developer advocate or developer relations specialist. I see evangelists as broader and speaking usually from the top down, where DevRel is all about speaking more precisely and from the bottom up. Having developer relations is essential for any product-led motion, helping educate and engage with the developers who are in the trenches, providing the stories, artifacts, and tooling they need to be successful in their work. In developer relations workshops and trainings you end up providing a lot of the hands-on knowledge that's needed to move businesses forward, often filling in the gap left behind when companies neglect to properly invest in developer education and training, while also focusing on the products and services a company is purchasing (or not) and putting to use across operations. #### Sales Engineers Sales engineers bridge the gap between sales and technical expertise by explaining complex products to customers, preparing and delivering technical presentations, and providing sales support. They work with sales teams to understand customer needs, identify pain points, and ensure the proposed solution meets the client's technical and business requirements. As a Chief Evangelist and Head of DevRel, it's important that this work is aligned with the stories you're telling, and that feedback and insight from these conversations are considered as part of your overall product roadmap, go-to-market strategy, as well as any ongoing way that you're engaging with your customers, gathering insights early on in the sales cycle, and using it to inform everything else along the way. #### Solutions Architects Solutions architects design and oversee the implementation of technical solutions to meet business needs by 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—communicating complex technical details to both technical and non-technical audiences and managing project progress. The key difference here is that solutions architects are post-sales, where sales engineers are pre-sales, but there should be synergy between the two roles. As I said before, this is work that should be used to inform other functions. This is where I begin to question things, because most investors will tell you to invest here but not invest in professional services and consulting—without much guidance on what the difference is and why. #### Professional Services Professional services for a company are expert-based, knowledge-based, and non-physical services that help businesses operate, grow, and improve. They're provided by firms or individuals with specialized skills, rather than by selling a physical product. This is a grey area when it comes to startups. Some companies have professional services groups but many do not. We saw companies like OpenAI go all in here, but again you don't hear the nuance of the difference between sales engineers, solutions architects, and professional services from people who are telling you not to get too involved in this work. I fought for a professional services group at Postman the whole time I was there and repeatedly lost the battle every time I pushed for it. My desire was mostly to scale myself, but I was told at every corner that it was a quagmire despite me being flown around the world to do the work. #### Value-Added Resellers (VARs) In the IT channel, value-added resellers, or VARs, are organizations that enhance the value of third-party products, such as original technology from our vendors, through activities, services and features like installation, providing additional hardware, consultation services, integration, product support and troubleshooting, and much more. This is an area that startups should be cultivating and building relationships with over time. They provide a great doorway into enterprises, but sadly I don't find them always up to speed on the latest API practices, and they tend to focus on the more entrenched software solutions and don't always represent the long tail of SaaS that I'm working with companies to put to work in any sort of concerted way. #### Systems Integrators (SIs) A Systems Integrator, or SI, plays a similar role to that of a VAR in that they combine the 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 many SaaS or open-source solutions, this is an important area of investment as a company. How your software and the software you're building upon work in concert is important, and having a trusted external organization or group of organizations available to do this work is a key part of any startup strategy. I feel this reflects where the whole VAR space will head and will continue to be shaped by APIs and open source. #### Managed Service Providers (MSPs) Managed Service Providers, or MSPs, are another one where the principle is directly in its name. An MSP is an organization that delivers outsourced services in conjunction with the hardware and software solution being provided to an end user. MSPs are taking the software that's in use and providing a more white-glove and high-touch approach. This is a great way to offload the expertise needed to another company. I predict that MSPs for open-source and sovereign solutions will continue to emerge as an important selling point for large global enterprises who operate in specific markets. Along with these managed services you get a lot of the expertise that's lacking in your average enterprise. #### Independent Software Vendors (ISVs) ISVs are often able to consolidate specialized areas of the martech stack to offer options to customers to help them complete their software requirements. Often, you'll find that major hardware vendors help out ISVs by rewarding the software vendors that make top-quality, compatible programs with valuable certifications. I need to do more research into how ISVs are operating so that I can understand how it overlaps with APIs and SaaS. I also don't fully understand the separation between MSPs and ISVs, but this is why I'm doing this writing—to help lay out the landscape, then do more work to understand how things work today, but also how it will work as cloud, SaaS, and AI continue to shape the landscape around us. #### Consultants Here is where we get closer to what I think people telling me we shouldn't do are coming from. Your average enterprise is likely doing business 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'm not just going into open-ended consulting arrangements with our customers, and I will need to have a strategy that overlaps with all of these areas to define what is "consulting" or "professional services" and push back on folks who are telling me I shouldn't be investing in this area. #### Domain Experts I want to make sure and bring in the ecosystem aspect of what Naftiko is doing here. We have an open-source core, which isn't just about standards and tooling, but also domain experts. The ecosystem surrounding open-source standards and tooling is full of domain experts who know their stuff. Companies are tapping this expertise daily, but like open-source standards and tooling—this is not being accounted for. The knowledge, practices, and processes of these domain experts are part of every player I've listed above, but also an area I am NOT told I shouldn't be doing. I should definitely be tapping into the time and energy of these domain experts. I just shouldn't be paying them—which brings me back around to what Sam Ramji of Apigee and others have told me. This is why I'm getting to the core of this discussion, because open source and open ecosystems are at the core of why we're being told NOT to do consulting. I aim to crack this open more in 2026. #### Pundits I would be irresponsible if I didn't mention all the pundits out there telling people what to do. These range from actual analysts who know what they're doing to transient homeless snake oil salesmen who wheel their little wooden wagons to conferences and social media revivals to tell their stories. This is where most enterprises get their information. In workplaces where there aren't heavy investments in education, training, and skills development, you find a huge appetite for the information this class of pundit is putting out there. I talk trash on this layer, but honestly, I put API Evangelist in this category. I'm first and foremost a storyteller. I just believe my stories to be truer and healthier. I've learned throughout this AI phase that many others feel the same about their work, despite evidence to the contrary. But if enterprises are listening to these stories, I have to consider them as part of this landscape. #### Guiding Naftiko Customers This leads me to why I wrote this post. I'm determined to guide Naftiko customers in all the ways I have as API Evangelist and Chief Evangelist at Postman. I'm determined to win my arguments with investors, advisors, and others who tell me that selling "consulting" services is a bad idea. I want the evidence to educate and defend what I'm doing. I also want to open source what I'm doing. I want to piss off all the people who gatekeep and police the knowledge and practices that exist in this dimension. I want domain experts to make the money they need to survive. I want to help folks on the ground floor of enterprises get the knowledge, practices, standards, and tooling they need to be successful despite their leadership not wanting to properly invest in these areas. I'm not going into the development of Naftiko marketing, sales, developer relations, sales engineering, and solutions architecting without a plan. I intend on cultivating my understanding and relationships with VARs, SIs, MSPs, and ISVs. I will continue historic work with EY, Deloitte, and others. I will continue my historic work with Gartner, G2, and other analysts. I will keep hustling with my snake oil brothers at conferences and via rest areas along the information superhighway. I will convince more investors to help invest in open source and the domain experts across every industry. I'm determined to tap into the signals coming out of companies, organizations, institutions, and government agencies, while simultaneously incentivizing those within them to share signals around what they're doing and what they need. I'm not sure what I will ultimately call this effort at Naftiko, but it will span all of these areas I've listed. A couple of things I've learned here. I just don't think many folks are thinking about the entire landscape of getting what you need as a startup from your customers and soon-to-be customers, while providing them with what they need. I think folks are captivated by stories of scale at all cost, then honestly counfounded by why they are able to scale to a certain point and unable to go further. Without the feedback loops in place across these areas you become stuck. we hear the stories of consulting being bad so often over the years we retell it without much consideration for the overall landscape as well as where we are at with distributed open-source systems. Granted, there are plenty of times I should not be consulting and taking in money by the hour, but there are plenty of times when it will benefit both parties involved. Ultimately the lesson here for me is to know the when we should and when we shouldn't, while also being honest about what we take and contribute from the open ecosystem along the way.