What's your personal philosophy on when it's best to build, buy, or subscribe?
CTO in Healthcare and Biotech, 11 - 50 employees
It depends on the $, time, and constraints you have.CEO in Software, 11 - 50 employees
The decision philosophy should be based on time-to-value vs. team strengths. Long term revenue impact is the 3rd priority. Key considerations:
How much does the product or service drive revenue or cut costs and when could a purchased solution be onboarded vs. building something
What is the true quality of the team. Not just "can they build it" but can they build something that won't be a burden and keep it supported with a focus on continuous improvement
Are there leverage points that building your own offer; easier integration with on-site data sets, matches tooling and languages you already have, easy API integration points
What will you "not" be working on if you're working on this solution, tool, platform?
If there is a belief that the potential negative impact on margins will grow significantly over time, you have to determine the cost and impact of making a change from what you purchased to something you built.
There is definitely an opportunity to include additional considerations here, but perhaps the most important point is that you have to find a way to make a decision quickly. The worst option is usually the indecision option.
CIO in Education, 1,001 - 5,000 employees
Cost is always a factor - much like mentions, I'm looking to buy where I can and where I don't already have the right expertise on hand. I especially don't want to be further development in legacy technologies where I'm trying to reduce that technical debt.Chief Technology Officer in Software, 11 - 50 employees
Buy or subscribe when needed and build only if necessary and a real business case exists. Spend time researching and really diving into the market as build always takes a tremendous amount of resource, time and ongoing costDirector in Manufacturing, 1,001 - 5,000 employees
First and foremost we always search our software inventory to see if we actually own the software already, or licenses for X number of seats that are not fully utilized. You would be amazed how often Aerospace buys 10,000 licenses but is only using 9,000 and the Petrochemical division only needs 100 licenses. We do get into some arguements over the charge backs on cost, but many times we find we already own what we need.We always try to go "Cloud" first as the priority, so SaaS. Then we will regrettably consider hosting the application.
The only time we build is for business critical knowledge where the value is in the secrets the business has. Our Chemical Engineering and Aerospace areas will occasionally build applications, but most of the time their employees are using purchased software or services.
CEO in Software, 2 - 10 employees
Build what you need and cannot buy. Buy what you need and cannot build. Subscribe to what is the best that you can neither buy or build.Chief Information Technology Officer in IT Services, 201 - 500 employees
The decision to build, buy, or subscribe for an IT service depends on various factors such as cost, time, expertise, and the specific needs of the organization. if you need customization build is better for example, if you need scalability well suscribe might be better. for now hiring is bad so you have to adapt you organisation for you market and needs. Director of IT in Education, 501 - 1,000 employees
Business requirement, reasonable cost, and Return on Investment. finally which one is the most saving and cost effective.Manager in Services (non-Government), 2 - 10 employees
It all depends on the individual situation. "Build" when there's no commercial equivalent to the product needed, "buy" when the desired features are available commercially, and "subscribe" when the product needs will change quickly or the cost savings of a subscription is substantial.Being an IT professional, I strive to make informed and cost-effective decisions when it comes to choosing which approach to use in a given situation. I weigh each option carefully before making a decision, considering cost, features, maintenance, interoperability, etc.
Content you might like
No plans on undergoing a migration yet34%
Currently deploying SAP S/4HANA27%
Migrating to SAP S/4HANA within the next 1-2 years19%
Migrating to SAP S/4HANA within the next 3-6 years10%
Already have SAP S/4HANA in production8%
3991 PARTICIPANTS
Segment15%
Bloomreach20%
Tealium AudienceStream CDP9%
Salesforce CDP45%
Adobe Real time CDP5%
Other (please comment below)6%
244 PARTICIPANTS
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Agree and add "...and manage."