Why you should probably build your product with an in-house team 👔
André J
28 replies
Someone could write a book on outsourcing software development - but essentially
- they have different incentives to you (get paid vs get product market fit)
- they are less motivated to solve any structural problems than you are
- if you don't know exactly what you want or don't express it clearly, you will get something else
- this is true for not just product decisions, but tech too, e.g. which tech choices they make
- if you are not careful you will end up paying them to build things that you don't need because they were able to convince a non-technical person that it was necessary
- if you don't interview the specific engineers that are assigned to your project then you may end up being misled about their skills or experience
- This is not to say that you can't make it work, but outsourcing is a skill
Outsourcing or in-house what do you prefer? Share your insights down bellow 🙏👇
Replies
Saranraj@sayoga
Absolutely, navigating the outsourcing vs. in-house team maze can be quite the adventure for businesses big and small. I've found that playing the field with a multivendor approach tends to hit the mark for a lot of folks out there.
You’ve touched on some really valid points, and I’m all in for making sure our clients are in the loop about the game plan. It’s like, we're not just coding; we're guiding them through this whole journey, step by step, making sure everything we do is synced up with where they want their business to head. It’s all about that partnership vibe, you know?
And, oh, the importance of clear communication and setting up a roadmap! It’s not just about the tech stuff but fitting it into the big picture of their business goals and timelines. It's kinda like putting together a puzzle where all the pieces need to fit just right.
I’m super keen to grab a coffee and chat more about this. Hearing your take and swapping stories could really shine a light on new angles we haven't thought about. It’s these kinds of chats that can really open up new pathways for tackling the whole outsourcing vs. in-house puzzle. What do you say @sentry_co &@busmark_w_nika ?
Share
Launching soon!
@busmark_w_nika @sayoga For sure. this is such a complex problem with no one fit answer. I think it's a really interesting topic. I was reading about how things get riggid yesterday in on the https://zed.dev/blog I.e that you can't always iterate forward, sometimes you have to start over. Because product architecture becomes stale and frozen in place. That's where the in-house collective knowledge really shines, because they have intimate knowledge of the product, to make it even better when they start over. But remote teams, often doesn't have this intimate knowledge, as it fades when they drop in and out of projects.
@sentry_co @sayoga I think it is about how much you are vulnerable to share with people (for example, information etc). But yeah, it makes sense that some things you can't share with people outside of your collective so this can be a point where external teams start to be "unconnected". When you want to build a strong company, you must start inside-out, to have strong people in the front line etc. This is not a convo for a few lines, we could talk about that for hours.
Launching soon!
@sayoga @busmark_w_nika I just feel that humans have more empathy IRL, And your empathy is sort of what makes you give a F**k. Also if you're at an office. there is nothing else to do than to be productive. no where to hide 😅. But of course, freedom of remote is magical. So your domed if you do and domed if you don't. 50% 50% might be the perfect setup 👌
@sayoga @sentry_co TBH, remote was the best thing that could ever happen to me. And during COVID... other people felt devastated... and I was experiencing euphoria. :DDD maximal disconnection. Oh, yees!
Launching soon!
@sayoga @busmark_w_nika I was already free during covid 😂 ... when it happened I welcomed everyone one else to the lifestyle 😬... but yeah. No one size fits all.
sometimes you also miscalculate and bring a person into the internal team who will end up doing it just for the money (I'm not saying they should do things for free - NO), but it's better when the team members share a common vision. And you can find such people in the outer circles as well. Depends. Personally, I've always been 50/50 in teams, such a renegade who shares the vision that's why I have been working with them for several years.
Launching soon!
@busmark_w_nika Aha. Best of both world! 50/50. Thanks for sharing your insights! And yes in-house team members can also stray, but it's less likely, as you form a sort of stronger compassion towards your co workers when you see them IRL everyday. IMO.
Agreed. The idea of trying to build a software company without being able to write software is crazy to me. Maybe there are one or 2 exceptions where this has worked in thousands, but the exception proves the rule in this case.
Launching soon!
@cwbuilds1 Yeah. It's hard to find success stories out there for low-code. Would love to be proven wrong tho! I think business people armed with AI code IDEs that get smarter and smarter could be interesting.
@sentry_co That's a good point. I'd say someone who is using AI to help them code is still coding, they're just using the LLM as a powerful tool
Launching soon!
@cwbuilds1 For sure. But they don't have to get into the nitty gritty. They can remain biz oriented and just do higher level coding. connect apis etc. build standard landing pages etc. I really like v0.dev I think this is the start of higher level coding.
@sentry_co Yeah, that's definitely true, and it's a trend that has continued since the invention of computers.
In the 90s, most developers had to work with lower-level languages like Assembly or C, which required a deeper understanding of computer architecture and memory management.
In 2024, most developers don't need to understand those fundamentals.
In 2040, developers may not even need to know what Javascript or Python are, but they'll still be classed as developers.
You and I won't think of them as developers because they can't write a python script. 'Not proper developers' is probably what the old school 90s developers think of us!
Launching soon!
@cwbuilds1 In 2040 you'll be writing apps by just describing it to your AI wearable 😏. Execute command 🚀 @maxjacobs
We were struggling with this too, that's why we decided to go with no code and build it ourselves. It's been quite the learning curve but we're enjoying it!
Launching soon!
@ruben_boonz How is making changes to the app in no-code? I always found that hard with no code GUI's. The GUI becomes overly complex over time to serve a wider and wider use case.
Launching soon!
@ruben_boonz I know bubble. How do you find it? Pros and Cons?
@sentry_co the biggest pro is the cost savings and how easy it is to build a full stack saas, the downside is vendor lock-in, so we don't own the code.
Launching soon!
@ruben_boonz I guess its a great way to test PMF early and cheaply. then later for v2 use more handcrafted artisan code.
Agree with your comments, and especially anything that is core to your product should be done by a dedicated in-house team. Some peripherals can be outsourced, some integrations, ancillary systems work (customer support etc) and if anything is outsourced, you need to have contracts stipulating ownership of IP from the beginning (not the end) of the project.
Launching soon!
@alina_cl Good point! I think a close knit team will outperform any remote team if they go head to head, and if conditions are right for the employees. Such as closeness to work, plenty of space to cocoon away from open landscapes etc. And yeah. Outsourcing tasks can be complementary, but it's also hard, you have to scope it just right sometimes that's hard when a problem is abstract. remote contractors can say it will take a week when it only took them 30min etc.
Well I can say that we worked on the application for a long time with our team and finally we turned to angular development agency. And after that we outsource everything related to IT right away )