[HN Gopher] Ask HN: Should we bring software dev in-house?
___________________________________________________________________
Ask HN: Should we bring software dev in-house?
I'm an executive at a mid-sized logistics company (~200 employees,
$200-300M annual revenue) getting more and more frustrated with our
software situation and am considering taking software development
in-house. I've been lurking here for years, so looking at the HN
community to talk me out of it. We're using a third-party product
that functions, but barely. The provider is understaffed and
unresponsive and the platform is stagnant. It's a fight getting
basic bugs fixed let alone new features implemented. We're having
to resort to a separate low-code platform to fill in the gaps. Our
business operates in a specific niche and there are no other
providers who cater specifically to our industry. As we are
growing we're running in to the limits of what this product can
offer. We're being hampered in our speed of execution and missing
crucial insights. I feel like we could do much better with a
product catered specifically to us. On the other hand, while our
current solution seems like a straightforward CRUD app, I fear the
devil is in the details. Will we get stuck at 80% completion? We do
a lot of data exchange via EDIFACT, for instance, with various
government institutions all over Europe. This feels like a quagmire
in which development can quickly stall. Besides, can we even
attract experienced developers to a non-glamorous industry like
logistics? We'd particularly appreciate input on: Strategies for
attracting and retaining tech talent in a non-tech industry
Experiences transitioning from third-party to in-house software
(success stories and cautionary tales). Potential pitfalls we might
not be considering. Alternative solutions we should explore. Has
anyone here navigated a similar transition? What worked? What
didn't? Any advice would be appreciated.
Author : 45HCPW
Score : 189 points
Date : 2024-08-05 13:43 UTC (3 days ago)
| PaulHoule wrote:
| https://martinfowler.com/bliki/StranglerFigApplication.html could
| be a good approach.
|
| You first need to hire somebody rather senior to be a "CTO" or
| "Engineering Manager" who is first of all supposed to help you
| consider "potential pitfalls" and "alternative solutions." Next I
| can picture that person putting together a 3-5 person team which
| could take a big bite out of your problem in the course of a
| year.
|
| Personally I have done many projects in e-commerce and I find
| logistics to be meaningful because I like knowing my system
| controls activity in the physical world. Today is a good time to
| be hiring software devs because the job market for software devs
| is softer than it's been in a while.
| fuzzfactor wrote:
| >hire somebody rather senior to be a "CTO"
|
| The right person fulfilling that kind of role can make all the
| difference.
|
| When there were no comments I wrote a little message which
| instinctively favors focused CTO effort myself:
|
| At the one extreme you write all new code.
|
| At the other you have a turnkey system using code that is
| already written, perhaps a system brought together by combining
| various task-specific apps.
|
| Or anything in between.
|
| You still may never be able to hammer _everything_ to
| perfection.
|
| Either way as much code as possible should be built against a
| completely non-moving target, with a core that ideally meets a
| stable unchanging foundational requirement, the objective here
| is to have a digital enhancement/replacement of a highly-
| performant optimized manual workflow, whatever can go forward
| with _no further updates_ or maintenance. Quite simply this
| makes for the best long-term investment if the code just plain
| lasts longer after it 's paid for.
|
| The moving-target stuff or component (which might include
| government regulations) might be better off "leased" since it
| might never be a very good investment anyway, especially not
| long-term.
|
| Either way a CTO or equivalent should be the ultimate expert on
| how this gets done in your specific company, having more than
| just domain expertise, but specific-company expertise on top of
| that. The deeper and longer-term familiarity the better, must
| be an absolute master of the detailed workflow before any type
| of irreversible commitment should be made. The level of trust
| needs to be up to the highest integrity of executives, there
| can not be a doubt that decisions are in the best interest of
| the company.
|
| You may already be a true master of the workflow and with
| enough mastery be more suitable for directing a team that could
| craft the most ideal solution, as long as you _actually know
| how to program computers_. You wouldn 't really need to be up-
| to-date on any specific languages that are popular now.
|
| _Someone_ needs to fill or acknowledge a CTO role, pick up the
| ball single-handedly and don 't make another move without
| making sure where the correct goalpost is. A little lonely
| indecision when you first pick up the ball is worth it if a CTO
| can then lead a team most directly to the desired end zone.
| Building a team from the ground up if necessary. It may not be
| completely necessary, but when that's not off the table, it's a
| whole new ball game anyway. More options, but probably gives
| rise to additional levels of uncertainty that need to be
| resolved.
| PaulHoule wrote:
| Right, and notably you want the CTO whether or not the answer
| is: * build a team in house * bring
| in some contractors * make the most of the existing
| vendor through API integrations * switch to a
| different vendor * some combination of the above
|
| because somebody with the right skills, attitude and
| integrity has to be in charge of it.
| fuzzfactor wrote:
| Yes the right person should be able to handle any or all of
| it.
|
| If you don't do it right it won't necessarily be more
| suitable than it already is, and when that's the stakes
| there's got to be a responsible individual who can put in
| full-time effort however much it takes, with the resources
| appropriately allocated to back it up. The same CTO needs
| to be capable of single-handedly being the only "tech"
| employee, served by their own carefully orchestrated select
| contractors, or at the other extreme capable of building an
| in-house team to make things better from the ground up if
| more beneficial.
|
| One person will have to make sure it comes out better than
| it is no matter what, or it's less likely to come true.
|
| Regardless, it can be like servicing airplane engines in
| flight, so that's another outstanding skill to keep an eye
| out for.
| 45HCPW wrote:
| Your and Fuzzfactor's points are very well noted. To do
| this well we'd need someone who understands the
| domain/industry/business and who is able to set a coherent
| strategy. The rest follows from there.
| mmdesignsldn22 wrote:
| Hi, are you looking for support to build a team out?
| Thank you.
| fragmede wrote:
| there's another option: buy the vendor. in the absence of
| details, it's unclear if this is even feasible, but the
| vendor already has the software they need, it just needs
| additional work done on it. so instead of reinventing the
| wheel, buying the vendor allows you to fix the existing
| one.
| lostlogin wrote:
| I was wondering if a starting a new company was a better
| way.
|
| It has one customer (initially).
|
| If it doesn't pan out you can drop that shitty vendor.
| nonrandomstring wrote:
| Or just the principal person behind the product. Careful
| approach and they may jump ship.
| steve_gh wrote:
| I have worked in a senior role in asset management (think bridges
| not derivatives!) for 10+ years, and this sounds like a familiar
| problem. A few thoughts:
|
| 1. You don't necessarily need to bring your development in-house.
| But you are looking to move away from your current provider. You
| might want to think about using contractors to build a new
| platform - possibly hire a software house to do it for you,
| rather than hire individual contractors. There are lots of small
| software houses who would love the opportunity to build a long
| term relationship with a client of your size
|
| 2. You need to be clear about your budget. How much are you
| paying your current provider? What would the development cost?
| What are the opportunity costs of the missing insights you are
| suffering from. What is the RoI on a new platform?
|
| 3. The absolutely critical thing you need to think about from day
| 1 is the migration onto the new platform. How are you going to
| get data off the old platform onto your new platform? How are you
| going to introduce the new platform. Can it be a phased
| introduction or is it a "big bang".
|
| 4. You need to have some good people in your organisation to
| manage the migration. People you trust to tell it like it really
| is, not to tell you what you want to hear.
|
| 5. I would recommend that you start by identifying the absolute
| minimum functionality you need to keep your business running
| smoothly. That is your initial platform (the MVP). The data you
| need for that MVP is the data you need to migrate initially.
| Don't try to do anything more than this in your initial migration
| - keep everything as simple as possible.
|
| 6. Do put procedures / checks etc in to ensure you maintain data
| quality across the migration. And if you can clean up the data as
| you migrate, so much the better. Do test all your data migration
| and platform migration before doing it for real!
|
| 7. After the migration, you then keep building the functionality,
| and bringing more data in. But concentrate on stability and
| keeping your business running. Your migration should be invisible
| to your customers. If you are having to making excuses to
| customers about why you suddenly can't do things, or meet your
| normal standards, then you are doing it wrong!
|
| Hope this helps :-)
| 45HCPW wrote:
| Thank you. This is very helpful. Getting the data of the old
| platform should not be a huge issue. Because we're filling some
| gaps with a low-code solution, the infrastructure to get data
| out is already there.
|
| Feasibly, we could replace functionality bit by bit.
| uticus wrote:
| > We're using a third-party product that functions, but barely.
|
| > Our business operates in a specific niche and there are no
| other providers who cater specifically to our industry.
|
| _If_ you decide to do in-house, I'd recommend thinking about
| competing against existing as a new revenue stream, and spinning
| it off as a separate business unit as much as possible. I imagine
| this is implied in your question but it wasn't specifically
| mentioned.
|
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| Yes. Are you kidding? Non-glamorous reads as safe in uncertain
| times. It's a positive point that will be a marketing multiplier
| for attracting talent, if coupled with other indications that
| your business has clear goals and good ideas.
| 45HCPW wrote:
| Yes. Clear goals is the big one. There is a lot to gain in our
| industry, in terms of technology. We've seen a lot of
| disruption plays coming from VC backed tech companies but I
| hope coming at it from the 'other' side, the industry side, can
| create great value too.
| Closi wrote:
| IMO spinning off comes with it's own complexities in terms of
| product - If you are writing it for 'in house' you are writing
| bespoke software to your own requirements, but there are
| players out there in the logistics software market (across most
| verticals) that are making products designed to support
| different configurations / businesses / processes by default
| (i.e. the business logic isn't as rigid as you would build it
| for your own in-house software, and you build the software
| differently if you are designing it to be used as configured
| software rather than just to support your own requirements).
|
| Would be interested to know the industry and any specific
| requirements that are very unique!
| layer8 wrote:
| > If you decide to do in-house, I'd recommend thinking about
| competing against existing as a new revenue stream, and
| spinning it off as a separate business unit as much as
| possible.
|
| That's taking the second step before the first. If this is
| going to work at all, first try to build a solution that works
| for _you_. Once you have that, then there _may_ be a chance
| that others will find it useful as well, but it is a whole lot
| of additional work to turn an in-house solution into a proper
| product, and your in-house needs are unlikely to translate 1:1
| to other companies, and vice versa.
| pbronez wrote:
| You're both correct. Absolutely you need to start small and
| build confidence over time. However, it's important to know
| early if you plan to eventually make the product a profit
| center. You can establish legal and technical foundations
| that will make your life much easier down the road.
|
| Another option is to consider building in the open. If the
| technology is not a differentiator in your industry, then
| maybe you build it open source under GPL. That way you can
| build a consortium of similar firms to build a genuine
| alternative to the status quo while preventing lockout.
|
| You don't have to decide about proprietary vs open source
| release now... but you should consider taking steps to
| preserve those options down the line.
| hamandcheese wrote:
| +1. Last startup I worked at basically tore itself apart
| because certain leaders fantasized about spinning of "AWS for
| X" before we had even met our own needs.
| physicsguy wrote:
| On this point it's worth noting that internal users are
| very very different from external users too.
|
| An internal user that can wander over to Bob and say hey,
| this thing isn't working quite right, I'll grab a coffee
| with you and we can talk through it, is very different from
| a paying corporate who will not tolerate service falling
| below a certain standard. I joined a company where they
| were trying to transition an internal piece of condition
| monitoring software to be a SaaS app and it went really
| badly wrong, the sales people seemed to assume it was ready
| for this but it just wasn't and needed a huge amount of
| hardening and security work, not to mention features to
| make it easier to use.
| bobertlo wrote:
| Remember that writing bespoke internal software and general-
| purpose commercial software are very different things with very
| different budgets, and you will need support staff. Do your
| research and talk with someone who understands _commercial_
| software before planning any kind of spin off. These are two
| very different goals, even if one would hypothetically fulfil
| the other.
| empath75 wrote:
| Also logistics sort of famously has interesting computer
| science problems to solve.
| ericmcer wrote:
| Definitely could attract talent, not only is stable job but it
| is green fields with flexibility to choose your own
| technologies and build something ground up.
|
| Most engineers don't love joining a giant co. and using tech we
| are not fond of.
| pierreia wrote:
| Hi, I'm thinking about exactly the same problem right now.
| Bringing in house devs to a "legacy" industry business, that has
| poor use of some digital services... This could really brings an
| advantage, and I'm sure nowadays software engineers could really
| be interested in working on "tangible" subjects rather than some
| bullshit saas...
| pierreia wrote:
| by the way, we could discuss that further if you want, you can
| send me a message on twitter: @pierre_ia
| kingkongjaffa wrote:
| > We do a lot of data exchange via EDIFACT
|
| I dunno how technically difficult this is, but consider either
| hiring an expert on this stuff, or hiring your core software
| engineering team, and hiring a consultant/freelancer type who is
| an expert in this stuff to get it done / up and running.
|
| > Strategies for attracting and retaining tech talent in a non-
| tech industry Experiences transitioning from third-party to in-
| house software (success stories and cautionary tales). Potential
| pitfalls we might not be considering. Alternative solutions we
| should explore.
|
| Part of outsourcing, is you're not just buying the technical
| solution, but the support and potentially the liability if
| something goes wrong. So it's important to consider what
| secondary benefits are baked into using a third-party, and
| deciding if you have the ability and appetite to support those as
| well as developing the tool.
|
| I sort of imagine that replicating the tool / business process is
| the easy part, it's stuff like setting up and wrangling EDIFACT
| that will be the hard things.
| nivertech wrote:
| If it would cost $X to develop this system inhouse, you could
| write down the requirements and offer the vendor to add the
| missing features to their product on NRE[1] basis for the
| fraction of $X (including support and warranty).
|
| NRE means that the IP remain their, and they will be able to
| amortize the costs across multiple clients.
|
| Assuming that this vendor is unresponsive because they're not
| incentivized enough (e.g. fixed pricing or SW licensing fees),
| not because they're incompetent.
|
| Also, most software projects fail[2], especially inhouse ones. I
| would expect vendors to have a much higher "not fail" rate (but
| not necessarily "success").
|
| --
|
| [1] Non-Recurring Engineering
|
| [2] stagnation is also considered failure
| thijsvandien wrote:
| While I have no experience building software teams, I did
| navigate a few situations where a relationship between a business
| and a software vendor went sour. How long two parties can talk
| past each other is impressive sometimes. Once everyone is on the
| same page, seemingly insurmountable problems go away faster than
| you think.
|
| No matter what you decide, it sounds like in the short term
| there's no getting away from them. As such, I would attempt to
| open a dialog focussed on mutual success. If this is a niche,
| chances are you are as important to them as they are to you. Show
| genuine interest in the problems they are facing, rather than
| expressing frustration. Are they struggling in general? Perhaps
| there are ways to help them get back up to speed. What about you
| as a customer (e.g., too distinct a workflow) makes things extra
| complicated? Look for specific points of friction, and how to
| address those.
|
| A viable option, at least to get started, could be to use them as
| a building block. For example, handling that data exchange you
| mentioned. Establish a simplified format that is still detailed
| enough for them to do what they need. Then have your own logic,
| however complex, construct the input to their system. Add
| something in the opposite direction as well. Over time, you'll
| have more and more components that are easier to replace, because
| of their limited scope. Finding another vendor or building more
| custom solutions won't be all or nothing anymore, which is
| exactly where you want to be.
|
| Doing this in-house? I feel the challenges are already plentiful
| without that. Instead, lean more to the side of having a couple
| subject matter experts interact with a small(ish) software house.
| It wouldn't be the first time that eventually one of theirs jumps
| ship, tagging on a colleague or someone else from their network.
| Basically the team would build itself, organically.
|
| On a final note, I just wanted to say this sort of stuff
| fascinates me. Likely you wouldn't have time for anything like
| that, but I'd love to see in detail what your business is doing,
| and how said software is holding you back.
| nocubicles wrote:
| I would get an open source ERP platform that you can extend
| yourself - for example Microsoft Dynamics Business Central or
| Odoo and start building on top of that platform. These platforms
| already have edi modules and all other basic functions such as
| sales and purchase module, finance etc. That will save you tens
| of thousands of development hours and you can start building your
| custom processes straight away.
| bruce511 wrote:
| I've been on both sides of this question so my views are both
| biased, and experience driven.
|
| In the early 90s we worked as contractors to a company developing
| (DOS) software for them. They sold and supported it. They got
| acquired and after another year the new owners decided we were
| too expensive and took the development in-house (as was their
| right under the contract.) We moved on to some other things.
|
| Bearing in mind this was simply a continuation of the existing
| product, not a rewrite. They encountered the following problems;
|
| A) there were no existing senior people on staff with software
| development skills. So they hired a couple programmers but with
| no clear vision of architecture and no clear understanding of the
| implications of short-term decisions.
|
| B) it was already a "big" system, so it took time for new
| developers to get up to speed. Their developers would get a job
| offer somewhere else (paying more) so they had to get
| replacements. (Remember bringing the development in-house was
| supposed to be a cost-saving exercise, so they didn't overpay.)
|
| C) over the 6 years they stewarded this the product was
| essentially stagnant, with no major changes or additions made.
|
| 3 years after they took it in-house we spoke to them about a
| Windows product. We would build it (and pay for development) they
| would sell it (we'd get paid-per-sale). This took 3 years to
| build, and once that shipped the in-house work was abandoned.
|
| My lessons from this saga were;
|
| Developing in-house is _expensive_. And forever. Staff posts you
| add to do this will always be there. Development of big features
| will end, but maintaince is forever.
|
| Whatever you have budgeted for this, it'll cost 10 times that.
| And probably 2 to 3 times your (current gustimate) budget for
| years after that. If you plan to recoup thus investment selling
| to others (we did) add another 0 on the budget. Going from in-
| house to "product" is not cheap.
|
| You will need a senior systems architect who stays over the long
| run to make long-term decisions and to give the project
| "coherence". Some early decisions can be very important down the
| road.
|
| Hiring is hard. You want people good enough to do the job, but
| who are also looking for job stability. Be prepared to look again
| every few years (unless you get lucky.)
|
| My advice; figure out your budget. Have a sit-down, at very
| senior level with your supplier. Discuss your long-term
| relationship. Discuss how much you are willing to spend. Discuss
| how you might make the deal attractive to both parties. Make
| yourself important to them.
|
| By FAR this will be the cheapest approach, and the least
| distracting for you.
|
| If you can't come to a deal, figure out what it will take to
| transition the existing source code to you. Probably a big pile
| of money. It'll still be cheaper than writing from scratch.
|
| Ultimately recognise that software development is expensive, and
| the management of it is hard and distracting. (And in many ways
| counter-productive). Your best hope is to rekindle your
| relationship with the provider, which recognizes that you need,
| and want, to pay a _lot more_. If there are reasons they can 't
| actually do what you need anymore then figure out the best way
| forward from that.
| dualogy wrote:
| > We're using a third-party product that functions, but barely.
| The provider is understaffed and unresponsive and the platform is
| stagnant. It's a fight getting basic bugs fixed let alone new
| features implemented.
|
| If that product (area) could be named or sufficiently-described,
| the audience size & substance here on HN might lead to 10 new
| hungry sleek alternatives popping up within a quarter, which
| won't be satiated=stagnant for years to come and keep it
| maintained and improved to customer feedback (if they find takers
| and a keeping-the-lights-on adoption curve). It's a hacker but
| also startup forum. Why not, while gathering all this good advice
| on your question, also share what this is all about in terms of
| _what_ in your niche / b2b market corner is currently badly and
| under-served?
|
| Plenty currently-underoccupied top talent here noodling on their
| techie pet projects while hoping to hit on some obscure /
| vertical / niche-specialized but promising real-world _making
| &shaking_ (ie. sth to found build launch & expand) opportunity.
| =)
| aswerty wrote:
| Sound like you should be doing a proper cost/value/risk analysis
| of the current solution along with a proposal for change.
|
| Once you do that you will probably have a reasonable
| understanding of your potential: budget, opportunity cost, RoI,
| risk, etc. for undertaking some kind of organizational change.
|
| The actual software development side of this seems secondary
| until the above is done.
| trumbitta2 wrote:
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| Pay a decent amount + meaningful perks (yes insurance, no tennis
| table), be decent people, give them agency and let them see
| they're making an impact, allow them to use whatever hardware and
| software they think it's best to do their job, don't force them
| out of remote work if remote work is what they want, be decent
| people, be decent people, keep bureaucracy and excessive process
| out of their way, and last: be decent people.
| dyeje wrote:
| I was the technical cofounder of a logtech startup. Logistics has
| a lot deep problems that need to be well integrated for a smooth
| UX. I think this is why you tend to see people eventually try to
| pivot into building a TMS (and why it takes so long to build
| one). They start solving a specific problem. They realize it's
| not worth much without the whole picture and nobody wants to let
| other players integrate.
|
| If your specific problem is well contained enough, it could be a
| good fit for in house. You mention that you're filling the gaps
| with a low code platform. You could perhaps experiment with
| moving that piece in house as a trial run. You also say that your
| existing platform is stagnant, perhaps you could acquire them or
| the specific IP you utilize. You might learn some valuable
| insights about what you'd need to do in house even if you don't
| end up seriously engaging in an acquisition or if it ends up
| falling through.
|
| I wouldn't be concerned about attracting talent, plenty of
| engineers in logistics already and it's a hirer's market right
| now.
|
| Anyway, the devil's in the details as you mentioned, my contact
| info is in my profile if you'd like to chat, happy to give what
| perspective I can.
| debacle wrote:
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| Treat your product team like wizards, not a cost center. Make
| sure the product director is a tech hire with business chops, not
| a sole tech hire (will let the team resume build) or a sole
| business hire (wont understand the peaks and troughs of
| velocity).
|
| Ensure that the customer is clearly defined internally, that the
| KPIs are oriented towards the bottom line, and keep things well-
| oiled but lean.
|
| Your best solution would be to spin off an internal company with
| eventual plans to commercialize what you build. You want someone
| with startup/entrepreneurial experience.
|
| Anyone who promises you a product within 3 months or tells you it
| will take more than 12 months for an MVP is snowing you.
|
| Happy to chat more, my email is in my profile.
| codingdave wrote:
| This is a variation on the "build vs. buy" question that has been
| active in IT for decades. And answered for decades, too. Building
| something yourself makes sense only when that something drives
| the unique value prop from your business. But if your needs are
| something that is more generic, buy it.
|
| So it all comes down to what you said about operating in a
| specific niche. If that niche is your value prop, and the reason
| software is difficult for you, then yes, in-house it and build
| what you need.
|
| As far as retaining talent, money talks. Put a number on the
| value that solid software would bring to your business, and if
| that number can support compensating a software team at market
| rates or higher, you have the potential to retain a team.
| However, it also needs to be a good team -- solid leadership,
| with a culture that matches what is expected by software devs:
| respect, autonomy, flexibility, and trust.
|
| If all of that sounds reasonable, go forth and build. If not,
| accept the struggle of having to buy.
| from-nibly wrote:
| Yes, and also when you hire software developers you want
| someone who understands that they are running internal tools
| which is COMPLETELY different from building consumer apps.
| Simplicity is key. Keep the team small and lean.
|
| Also the build vs buy decision has to be made with every
| feature. If its not your competitive advantage just buy it.
| Dont make a new database, just use postgres etc.
|
| There are a different set of developers that can navigate
| through this than the ones who will reinvent the wheel if they
| can.
| motherfsck wrote:
| I've not worked in the logistics industry or with edifact
| specifically but have dealt with phased removals of large "turn
| key" products in a several heavily regulated industries. I've
| also gone the other way where we've replaced in house solutions
| with vendor provided software.
|
| Email is in my profile, feel free to reach out. Full disclaimer,
| we're a small consulting/contracting agency but I'm still happy
| just to talk shop.
| codegeek wrote:
| If this product is critical to your core. business, bring it in
| house. If not, then keep it 3rd party but look for a
| replacement/new vendor.
| mindcrash wrote:
| > "This feels like a quagmire in which development can quickly
| stall."
|
| It depends. In the end EDIFACT is just a protocol. If you go the
| Java route Smooks, for example, has pretty decent support to
| read/write EDIFACT messages.
|
| If you do not want to do the heavy lifting yourself, both AWS and
| Azure provide SaaS services to do the heavy lifting for you (AWS:
| B2B Data Interchange, Azure: Azure Logic Apps)
|
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| If you can provide a good salary and conditions: absolutely. And
| I should know, because my previous stint WAS in logistics :)
|
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| Provide a great work environment, good salary and conditions
|
| > Experiences transitioning from third-party to in-house software
| (success stories and cautionary tales)
|
| Start as easy as possible and don't hire anyone who wants to
| build a microservices based platform from scratch w/ almost zero
| domain knowledge at your org. Because that road _will_ lead to
| nowhere. (Ask my previous colleagues who decided "we" should. I
| was against. They are still working on it, 3 yrs later, and
| nothing has been deployed yet because it _still_ does not work
| properly.)
|
| > Potential pitfalls we might not be considering.
|
| Do not go the microservices road unless you really, really,
| really have to (and with good arguments!)
|
| Need any more tips? Happy to help.
| RangerScience wrote:
| > It depends. In the end EDIFACT is just a protocol. If you go
| the Java route Smooks, for example, has pretty decent support
| to read/write EDIFACT messages.
|
| You can also do shim servers to translate between protocols - a
| long time ago, I had to interface with a Rails app (by another
| team, so I couldn't modify it) with an Emerson (the industrial
| giant) SOAP API, and what turned out to be effective was a
| Sinatra shim server that _only_ converted JSON to SOAP. Now I
| could plug the two together without worry.
|
| So - I'm guessing you could have a Java Smooks applet that
| translates from a JSON API to the EDIFACT protocol, and then
| you can write your main app in anything you want.
|
| PS - Seconding the "don't go microservices", even though I'm
| advocating for one here - IMO, you only want microservices if
| they can be fully defined, independent products; a JSON/EDIFACT
| translation service would probably qualify.
| mindcrash wrote:
| I think in this case a well defined modular monolith would be
| a excellent starting point, especially if you need to (1)
| build from zero and (2) hit the ground running with a small
| team (without all the extra things you need to pay attention
| to and create solutions for when going the microservices
| route).
|
| The great thing about the modular monolith is that it gives
| you a fantastic foundation to grow: You can still invest in
| multiple teams each handling a certain part of your problem
| domain (due to the modularity); and because it is modular you
| could easily break it apart, and evolve it, into a
| microservices architecture _if_ and _when_ there comes a time
| you need to do so (due to extensive problems getting code
| shipped, or difficulties concerning NFRs defined for the
| architecture, for example scaling issues in production).
| ensemblehq wrote:
| Whilst I don't have a ton of experience in logistics, I have
| helped executives in other industries map out transition
| strategies.
|
| For the software in question, a few considerations come to mind:
|
| - how critical is the software to your company's competitive
| advantage?
|
| - how big is the vendor team supporting the software?
|
| - how much revenue/customers does the vendor currently support?
|
| - how much of the software is entirely custom developed vs
| modules built on top of other platforms?
|
| - where does the software reside (on-prem/in-house acct vs mix vs
| vendor)?
|
| Without knowing too much detail about the situation, if it's an
| application that is easily testable and verifiable (I.e. perform
| an action results in observable actions), then it's much easier
| to rewrite than an application with background functions and
| procedures so some level of due diligence or discussion with the
| vendor maybe useful.
|
| Other alternative solutions that may make sense if software is
| critical:
|
| - joint venture with vendor
|
| - code acquisition + in-house team
|
| - code/team acquisition
|
| - short feasibility project to determine migration strategy
|
| I've worked fairly extensively in transition/acquisition projects
| so happy to share more if there's anything specific you're
| interested in knowing.
| cjblomqvist wrote:
| Lots of good comments in this thread, but I think this is a
| critical one. It seems you've (OP) almost already decided, but
| you're unsure about details such as how to retain software
| developers. Before you go into such details you need to be sure
| you want to make this move. This must be a strategic move,
| meaning a long term move where you're sure you're gaining a
| strategic competitive advantage through this being a core
| competence (in the academic/theoretical strategic sense). There
| are very few quick fixes in IT. Most projects are grossly
| underestimated - in particularly if you lack the competence in-
| house today (easily 10-100x).
|
| At it's core, it should be a decision that is not only about
| control over the software, it's about bringing the knowledge
| about the processes and technical complexities of doing your
| business in-house. You might think you know all about it, but
| most likely you don't (otherwise most IT projects wouldn't
| fail). The big cost in IT is specifying exactly how things
| should work (that's basically what coding is all about). If
| you're not a developer (and even most developers
| underestimate/don't fully understand this) it's highly likely
| you underestimate this part of it (otherwise it would be easy
| for you to code it yourself - again, how to code is not a big
| deal, it's specifying exactly how it should work).
|
| Software development is a lot about managing and documenting
| processes, aka knowledge, about your business.
|
| Otherwise I agree with lots of other comments. Make sure you
| and the rest of the business is sure and have enough
| budget/resources allocated for a long time forward. Bring in a
| CTO/leader with the experience/skills of doing something like
| this. Make sure that person has the mandate to do what's needed
| (hiring, culture, etc). Could be a good idea to do it step by
| step to test out (again, a good mindset is to see this as an
| investment in learning about how to do your business, using
| IT/automation). A hybrid approach could work (take over
| existing code, use another platform/ERP/system as a base) - all
| depends on the specifics of your business, how custom your
| business and processes really are, how core to your business
| they are, etc.
|
| Good luck!
| solardev wrote:
| Does it have to be one or the other? Can you contract the work to
| an agency, in effect leasing developers without having to bring
| them in house?
|
| I worry that without a culture to sustain and nurture a software
| team over time, whatever you build this year will become
| nightmarish tech debt a few years later. Dev turnover might be
| high due to limited advancement potential / lack of resume
| building opportunities / not enough sexy problems to work on.
| Institutional memory between generations of devs might be hard to
| maintain and your totally custom software might get harder and
| harder to work on and use as the years to by. It doesn't seem
| like a great way to run an essential part of your business.
|
| Can you switch to a more responsive vendor but then find an
| agency to do the day to day dev work and add custom code as
| needed?
|
| I've spent much of my career working in tech roles for non tech
| companies, and I've seen a lot of bespoke custom garbage that's
| really hard to work on. It ends up being more forensic than
| engineering work, with a lot more reverse engineering and
| landmine avoidance than new feature development or UI
| improvements. I try to steer these types of businesses into
| commercial off the shelf software whenever possible, but maybe
| building custom webhooks and such into them.
|
| It's a lot easier to have a solid base built and maintained by a
| good vendor, with some small snippets of modular code (webhooks,
| plugins, extensions, etc.) added on top. No one feature is tied
| into everything else, so less experienced devs can fix or replace
| it modularly without having to reverse engineer your entire
| custom stack.
| ensocode wrote:
| Interesting questions. I Work in the logistics/B2B area for quite
| some years and know this kind of problems well. I think in-
| sourcing development can be beneficial if your niche has so many
| special requirements and this is a core application. Or you can
| go with a trustworthy software house as a partner to be a bit
| more worry-free. Our customers usually do the project management
| and the requirements and we are taking care of the solution's
| technical aspects. In my experience this makes a perfect match
| especially in technically "non-sexy" environments like B2B,
| EDIFACT. On the other hand it takes time building trust from both
| sides.
| aantix wrote:
| If you move it in-house, I would recommend changing your
| application process to include a video portion. Unless they can
| point to a long track record of open source.
|
| All engineers are utilizing GPT to write their resumes/cover
| letters.
|
| The written word and keyword references are no longer a signal of
| ability.
|
| Give them a couple of questions to answer on video.
|
| Record the time when the questions were displayed vs when their
| video cover letter/resume was submitted to ensure they're
| organically answering the questions.
|
| Otherwise, be prepared to sift through literally 1,000+
| applicants.
|
| Hiring has slowed in the U.S. I wonder if in part it's because
| everyone now can submit a very qualified resume and it's become
| increasingly difficult to differentiate good vs bad candidates?
| Especially given the increase in applicants.
| Closi wrote:
| I'm a logistics consultant that specialises on the software side
| of things!
|
| What kind of logistics does your company do? (Transport,
| Warehousing or both?)
|
| Will depend a lot on your functional requirements, but I would
| say that unless you are doing something particularly unique,
| there are probably off-the-shelf products that do what you are
| looking for, and will probably be cheaper and more stable than a
| 3+ person dev team in house.
|
| I don't know what your requirements are, but if you are in any
| way a somewhat normal logistics provider, what you are looking to
| do will quite closely match an existing software package out
| there on the market (or more likely, multiple packages). Just
| because you have package which is a poor functional match at the
| moment doesn't mean there isn't one that better meets your
| requirements!
|
| In my experience home-grown systems give you exactly what you
| want in the short-term, and then come with massive limitations as
| you try to grow/scale them (i.e. if you are on the 3PL side of
| things, if you get a new client and have a good WMS you can
| probably on-board them purely with config without having to write
| code, despite them having some new/unexpected requirements), and
| the 'new' home grown system today becomes a legacy nightmare in
| the future.
|
| Plus home-grown logistics software often misses some critical
| component that makes warehouses function well (e.g. I have come
| across many that don't have hard allocation, and then find that
| they have pickface shortage issues that are hard to resolve!).
| Unless you are closely copying how other software works in this
| space, you will probably fall into pitfalls that are already
| solved.
|
| Assuming it is a WMS and you are a 3PL (my best guess from your
| description!), personally I think the best thing to do is get a
| good 'off-the-shelf' WMS and then dedicate your engineering
| efforts into the more customer facing side of things (e.g.
| customer portals) where you can actually show differentiation
| with your competitors. No point reinventing something that
| everyone else already has!
|
| If you are a 3PL on the transport side, there are also great
| options that cover 'business as usual' and you can again push
| some development effort towards the customer side.
|
| For logistics businesses, having software which is industry-
| standard and has a large support base is a bigger sell to a
| prospective customer than having your own 'great' homebrew
| software, but that's just my two cents.
|
| Slightly boring answer.
| mpeg wrote:
| So this kind of "platform independence" approach is something I
| have been hired to figure out a few times before as a tech
| consultant
|
| Often a very similar story to yours, what I find that works
| consistently:
|
| - Start small, don't plan to replace the whole platform in one
| go, but instead figure out what elements can be separated and
| replaced individually. Even if this means having to integrate
| with the existing platform it will be the better approach
|
| - Have a migration plan, even if you are replacing individual
| pieces of functionality each piece will involve retraining users
| and have its own quirks, so have a plan not just for the data and
| tech migration but for the user side of it
|
| - Focus your development efforts in the core of the business,
| leverage open source and SaaS for the rest - with a rebuild it's
| very easy to end up going way above budget and time if you focus
| on the wrong thing, this should also reduce scope creep
|
| - When it comes to onboarding developers the most important thing
| you can do is document everything as well as you can - that way
| if developers leave half way through the project you reduce the
| impact, and new developers will be able to ramp up quickly and
| overall be less frustrated
| insane_dreamer wrote:
| Having been in that situation and developed SW in house as well
| as hired third-party firms to do so, based on my experience I
| would go with in-house if 1) you have very specific requirements
| that need to be well understood and implemented, and which may
| require close collaboration with the teams who are actually using
| the SW; 2) the SW in question is mission critical; 3) you want to
| be able to make changes/adjustments fairly quickly without the
| overhead of administrative/contractual dealings with a third
| party (i.e., whether it fits under existing SOW etc.).
| 999900000999 wrote:
| I'd take a middle approach.
|
| Is their an open source solution to your needs? Do you really
| just need 3 or 4 people ( pay them top of the market, find senior
| level folks) to slightly tweak it ?
|
| Otherwise you might be looking at a very complicated and
| expensive development process just to get to V1. Software
| development for any thing complex takes a lot of time.
|
| >On the other hand, while our current solution seems like a
| straightforward CRUD app, I fear the devil is in the details.
| Will we get stuck at 80% completion? We do a lot of data exchange
| via EDIFACT, for instance, with various government institutions
| all over Europe. This feels like a quagmire in which development
| can quickly stall.
|
| Do you NEED an app. A simple internal website will be infinitely
| easier to build and maintain.
|
| This is worth hiring a consultant to just talk about what options
| are available. Preferably someone you know personally, a lot of
| contractors will try to take you for a ride.
|
| Do you have any programmers on staff right now ? You need someone
| on your side with a technical background.
|
| Do you understand taking this in house will probably cost and
| take more time than you expect ?
| ibash wrote:
| If you do bring it in house look for very senior folks, ideally
| ex-founders who've built a product from scratch. You want someone
| who can help figure out requirements, feasibility, and write
| code. Pragmatic engineers are always the best.
|
| happy to chat about this if helpful, email is in my profile
| purpleblue wrote:
| Unless you're willing to become a software development company, I
| would strongly strongly suggest NOT writing the software
| yourself.
|
| 1) Can you acquire this company?
|
| 2) Can you talk to other companies that do something similar and
| migrate to their platform? Or threaten the current company with
| them losing your business if they don't get their shit together?
| tristor wrote:
| I have helped a company do something like this in the past. My
| advice is go for it, but understand that there's going to be some
| landmines.
|
| The biggest benefit is that you likely have a stronger
| understanding of your needs than any third-party, and if there
| are other businesses in your niche, it provides you a pathway to
| build a revenue stream selling your custom solution to your
| competitors to capture part of their revenue. If you think about
| it from the perspective of value capture, it means even if you
| lose a deal on the front end to a competitor, you are capturing a
| percentage of it on the backend because it gets your competitors
| reliant on your platform. To do that though without running afoul
| of antitrust, you should try to set it up so in-house development
| of the platform operates relatively independently of the larger
| business (the legal term is "chinese wall").
|
| As an outcome, you can actually generate a new revenue stream
| that's profitable while correctly serving the needs of your
| business.
| snihalani wrote:
| > Our business operates in a specific niche and there are no
| other providers who cater specifically to our industry.
|
| I'd love to be the provider on this.
| austin-cheney wrote:
| So, base your decision only two factors:
|
| 1. Budget (perform a thorough cost estimate before making any
| changes)
|
| 2. Quality of service expectations
|
| The risk part of this is that your company has never had a
| software team before. This means you have nothing to build upon.
| The level of risk here is tempered by the flexibility within your
| available budget, which means how much cost are you willing to
| absorb outside of plan if this goes to shit.
|
| Now, set your expectations right. Software teams never ever make
| money. They only cost money. Will moving dev in house cost less
| money than the current solution? No, at least not at first, but
| you have to build from nothing. Moving dev in house will allow
| future scale the outside party does not provide.
|
| Secondly, absolutely forget technology. Don't fucking go there
| and if you do you have already failed. Think only in terms of
| leadership. What that means for this effort:
|
| 1. Hire a leader who can perform risk analysis, measure things,
| work within a budget, is super assertive, and communicates
| brilliantly both in person and in writing. The assertive part is
| important because opinionated technicians/developers will attempt
| to drive the plan. Don't ever let that happen. A real leader will
| own this in both failure and reward.
|
| 2. Set realistic goals and accomplish those goals. Don't do
| anything else. Once the first goals are achieved you will have
| the foundation to do other things. Every distraction wastes more
| of your budget.
|
| 3. Form, in writing, policies that you are willing to fire people
| for violating. These should enshrine conduct, ethics, and
| appropriate standards for quality of service.
|
| 4. Do not (ABSOLUTELY NOT) think about this in terms of a
| startup. You are an established company already generating
| revenue/profit with margins. Proceed with a well planned vision
| always accounting for risks and make adjustments to the plan very
| carefully. Distractions and deviations will cost more money.
|
| 5. Finally, transition from the current solution to the in house
| software team carefully and progressively. This will cost more
| upfront, but dramatically less in the near term due to lower
| risk.
|
| Good luck.
| tonyennis wrote:
| Do you have an email address? Shameless plug but this type of
| project is exactly what my small agency does, have done for
| several companies similar to yours.
| katzinsky wrote:
| Here's what I would do.
|
| Hire some people to start building it, publish the code under a
| copyleft license such as the GPL and start hiring consultants to
| contribute to it. This will give you control over the critical
| "must haves" while making it possible to eventually spin a lot of
| the maintenance off to third party companies.
|
| Software that's developed this way has a long history of being
| very high quality as there's much more cohesion and communication
| of theory when the developers and costumers work for the same
| company while at the same time the GPL will protect the project
| from potential takeovers via internal politics.
| webel0 wrote:
| Can you provide some examples?
| TYPE_FASTER wrote:
| I've worked at a large company that ran internally developed
| logistics software. It worked for them.
|
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| While you might be in a sector that isn't tech, you have tech.
| Put yourself in a software engineer's shoes, from a career
| perspective. We tried to keep up to speed with respect to things
| like framework/platform version, development practices, etc.
|
| Make it clear and obvious that you will continue to invest in
| technology. We went to mobile early because it made sense for our
| business. We continued to invest as mobile changed with the
| introduction of iOS, and as computer vision got better.
|
| Feel free to reach out if you want to discuss further.
| CrimsonRain wrote:
| The single most important thing is to hire the right person for
| leading (technical) this project. Even a tiny (<=3) (but well-
| paid) team can deliver you results beyond your expectations.
|
| There're interesting things to build in all industry; logistics
| is not an exception.
|
| I've seen stuff like this before and the most common reason for
| failure is the "technical" person focusing on entrenching their
| position instead of focusing on delivery.
| allanren wrote:
| Depends on your complexity, if the business is standard logistic
| process. Then there are plenty of ERP products to choose. Let the
| ERP company do the work, it won't be cost more than have your own
| team.
| sghiassy wrote:
| As a Principal Engineer in FAANG, I'd caution against bringing
| software development in-house without someone who deeply
| understands how software is built at the leadership level within
| your company.
|
| Software can be intangible, making it difficult to manage budgets
| and timelines. You might find yourself asking, 'We're spending
| all this money, but what exactly are we getting for it?' What's
| the point of all this CapEx?
|
| Moreover, it's easy to place unrealistic demands on software
| development. If you, the business, change your mind every two
| weeks about what the software should be or do, the constant churn
| in feature requests can bog down the code and hinder development
| --through no fault of the developers.
|
| While you don't necessarily need a CTO, it's crucial to have
| someone you trust, even when the answers you receive aren't what
| you want to hear.
|
| Is it possible to find a new outside vendor?
| zehaeva wrote:
| I spent some 13 years working for a manufacturing firm writing
| custom management software for a similar sized manufacturing
| company. I now work for a SaSS firm in a different industry with
| a few hundred clients.
|
| The thing that I learned from this is you either buy off the
| shelf software and run your company the way that the software
| company thinks you should run your business. You can, like some
| of our clients, fight the software and figure out all the janky
| work arounds you want, but ultimately you are bound by that
| software.
|
| Or, you can write your own software and run your company the way
| you want it to run, with all the weird quirks of your business.
|
| I get why smaller companies/firms buy software instead of rolling
| their own. It's a huge amount of overhead for little apparent
| benefit. It's worse when the software vendor isn't helpful or
| attentive to your needs.
|
| My gut would be to say find a few software engineers you trust,
| hopefully with experience doing EDIFACT files (I've done this
| myself and the specs are a bear to dig through). I have this
| feeling mostly due to the unresponsive software vendor and your
| operating in a small niche.
|
| For attracting talent, pay them well, and make them feel
| appreciated, and listened to. You'll be running a tight ship with
| very few points of failure (the bus factor), just one or two
| people leaving could paralyze your operation. You don't want the
| software people to start looking for jobs elsewhere in such a
| small department. My previous employer did not do well in that
| department and lost 90% of their software staff in a 3 year time
| span. And when your department is 4-5 people that's devastating.
| necheffa wrote:
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| As someone who is a tech lead at a non-tech company that does
| software in house for a niche product in a niche market...
|
| You can either treat the software as a product in it of itself
| (as opposed to bolting it on to other projects for your core
| business) or you should expect to include some hazard pay to
| compensate for the mental and spiritual trauma caused by trying
| to pretend you can treat the software like a line item in non-
| software projects that "just" need software support, ending up
| with 4-5 project managers trying to oversee/status a single
| software release.
|
| We do the latter and if some of the other benefits were not as
| good as they are, it would absolutely be a deal breaker.
|
| I suspect most other non-tech companies also operate in a
| similarly sub-optimal way (the blind leading the blind), but why
| would I put up with that level of ass-hattery for anything less
| than what the market can bear?
| koliber wrote:
| First, get a senior person to lead the effort. They need to have
| experience hiring and managing developer teams. Ideally, it is
| NOT going to be someone with a lot of wizz-bang shiny tech on
| their CV. You need someone who wants to understand your business,
| and will focus on business value, and swallow the elephant one
| piece at a time.
|
| > Strategies for attracting and retaining tech talent in a non-
| tech industry
|
| This varies, but if you manager to hire and retain 200 employees,
| I'm guessing that you'll do alright.
|
| > Experiences transitioning from third-party to in-house software
| (success stories and cautionary tales).
|
| If you have a decent manager and someone who can make sound
| technical decisions, you'll do well.
|
| > Potential pitfalls we might not be considering.
|
| You seem to have good awareness of the danger areas. Devil is in
| the details. Figuring out how to slice the problem and building
| things piece by piece will be important.
|
| > Alternative solutions we should explore.
|
| In general, outsourcing companies are hit or miss, but if you
| find a good one, you will get many of the benefits without the
| downside of managing software dev in house.
|
| Having a more seasoned person supporting the lead engineer will
| help you avoid costly pitfalls. I'm being self-serving, but a
| fractional CTO working a few hours per week might bring the kinds
| of safety check that will make such an endeavor more successful.
| kkfx wrote:
| The issue of doing in-house is the issue of finding competent
| devs, meaning not only "someone who code" but someone who
| understand how to PROPER design things, witch is essentially a
| lost art.
|
| EDIFACT is dramatically simple, far more than modern XML-based
| peppol alike dialects, here the issue is "just" knowing that very
| likely any "institution" might have injected a gazillion of
| personal stuff, mostly undocumented or badly documented to be
| take into account for a long interim, but developing a personal
| ERP trying the modern path is far from being digestible.
|
| IMVHO it's feasible trying to fish common-lisp/clojure world.
| That's a niche enough there is not much retention issue, and
| there are still skilled devs because it's a kind of niche where
| some arrive, try, fail and go, some skillful remain and do want
| to be there.
| mxvanzant wrote:
| I agree with @kkfx. lisp/clojure world is good to help with
| long-term maintainability, etc. To get an idea search for Rich
| Hickey's talk "Simple Made Easy"
| mxvanzant wrote:
| Here's that talk: https://www.youtube.com/watch?v=SxdOUGdseq4
| jtriangle wrote:
| As a business decision, having on-staff developers mainly comes
| down to value.
|
| Can those employees generate their salary in value? How long can
| they do so?
|
| It makes little sense to in-source dev if you have 6 months of
| work that revolves around bugfixes. Less still if what you're
| building isn't saleable, which in your case it sounds like it
| isn't.
|
| The other side of this coin is, you suck at dev management. Your
| whole company does. All companies start at that point. Any
| project you pickup at this point is going to feature creep to the
| moon and cost 2-3x as much as it should because it's not going to
| be well defined, and it's not really going to accomplish what
| you'd like to accomplish.
|
| The best advice I can bring you is, take on a SMALL project
| first, very small, like a single-purpose app, pick one thing at
| your company that really sucks to have humans do and isn't
| complex, build an app to do that. Probably use outsourced
| contract dev/devs to do it, have them bid on it. Make sure your
| product requirements are bullet pointed out and crystal clear.
| Your mother should be able to understand them. Do not set an open
| ended timeline, because you're going to get high bids as it's a
| clear sign you're a newbie and are going to be expensive to work
| with. Project check-ins/meetings should be defined and scheduled,
| create stages and meetings for those stages, and review them upon
| completion, again, all defined in the project pitch.
|
| Basically, you want a developer to be able to take what you've
| written, and complete the project with no surprises.
|
| Do that a few times, make the project a little bigger each time.
| You will learn alot, and once you have a few things under your
| belt, you can start to consider hiring your own dev team.
| unholyguy001 wrote:
| In a lot of companies the root cause of this kind of thing is not
| being willing to spend the kind of money needed to achieve the
| desired result
|
| You need to be honest with yourself about whether you can
| actually afford what you what to do.
|
| The other side is it's not unusual to see a company getting bled
| by an entrenched third party
|
| Whichever case you are in, start small and prove the value with
| something tangible
| prewett wrote:
| I've worked at an online retailer which uses custom code for both
| warehouse operations as well as corporate operations, similar
| size as you. The dev team grew over time, but was on the order of
| 10 people.
|
| You absolutely can attract talented developers; this company
| preferred to hire very experienced people, and that translated
| into minimal management. (Which also created a high level of
| ownership by the devs, because they can proactively fix what
| needs to be fixed and directly add/fix what people/users are
| complaining about.) They also used a functional language, which
| tended to limit the pool of available people to people who were
| capable of quickly coming up to speed.
|
| Even after you have something working, you'll probably end up
| having to do a fair amount of development just to "stay in
| place", since the needs of the business are (presumably)
| constantly changing. Sometimes this can take longer than you'd
| like. But the advantage is that you get exactly what you want. If
| you're struggling with your current software, it seems reasonable
| to write your own. You might want to start with writing just the
| most frustrating part, and then the next frustrating part, etc.,
| rather than trying to implement the whole thing. Especially at
| the beginning it makes the project smaller, lower risk and you
| get more successes along the way. And if it doesn't go well,
| you'll find that out earlier.
| dilippkumar wrote:
| My email is in my profile. Here's an offer.
|
| Let me build this thing for you. Exactly, to your specification,
| by sitting and working with you and your team, and solving
| exactly your problems.
|
| Once the solution is done, you can either buy the software org
| from me or chose to license it from me.
|
| Happy to talk details.
| wkirby wrote:
| Unless this software is your core business, I would look at a
| third alternative: contracting the work out to experienced
| developers to replace the platform.
|
| If it works well, you can bring development in house slowly after
| the platform is more mature. Worst case, you'll have a more
| responsive external party managing the platform for you.
| from-nibly wrote:
| Worst case is that you don't know how to run a software team
| and you end up spinning your wheels for ages and then have to
| onboard a Dev team and convince them they want to clean up
| someone elses tech debt. Thus making everything cost 10x what
| management initially thought.
|
| This is probably the last thing I would suggest.
| brianbreslin wrote:
| My team has been building custom software for a large german
| multinational shipping and freight forwarding company for 18
| years now. Happy to chat, my email is in my username @ gmail.
|
| Our client has tried what you're discussing several times. They
| are a bit bigger (10x) than your org, but never built up the
| software muscle in house despite hiring and firing entire teams
| to attempt to build stuff in house. We've handled one corner of
| their offerings for nearly 2 decades while all their other teams
| have cycled in and out of internal and external suppliers.
| rgblambda wrote:
| I'm not a business person so I don't know how insane this might
| sound, but would your best bet perhaps be to reach out to your
| competitors and other businesses you think are in the same
| situation and propose some sort of shared software house to
| replace the 3rd party solution?
|
| It seems rather expensive for a 200 person company to start it's
| own software division just for internal applications.
| frankfrank13 wrote:
| > The provider is understaffed and unresponsive and the platform
| is stagnant.
|
| You need a new vendor, if you can't afford it, you may not be
| able to afford a proper in-house team. I've worked with great
| vendors that would not give you this experience, and vendors that
| would you give you far less than you're getting now.
|
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| Yes of course you can. But reach out to engineers in your network
| that work for non-FAANG companies and understand why.
| bdcravens wrote:
| Working on logistics software has been my day job for 14 years.
| You can attract experienced developers by giving them autonomy,
| GOOD pay, and a healthy work environment. I wouldn't trade a
| "cool project" for any of that.
|
| It does sound like the best solution would be to bring most of
| the development in house, but integrate with third-party APIs
| where it makes sense (ie, the data transfer piece you referenced)
| RangerScience wrote:
| >I wouldn't trade a "cool project" for any of that.
|
| something-something "Life is short to deal with problems we
| didn't have to have"
| davedx wrote:
| IME what works best getting new projects kick started is hiring a
| very small team of senior freelancers, making one of them lead,
| and letting them loose. I worked on such a team once and it was
| really excellent. The advantage of this strategy is if the
| experiment doesn't work out, terminating freelancers is much
| easier than permanent (I noted you're based in Europe).
|
| Contrary to what other people said, I wouldn't try find a CTO
| straightaway. It's a hard role to hire for, _especially at the
| start_. I think you 're better off unleashing a small, excellent
| team of builders then hire management later to help build out the
| team if the initial effort succeeds.
|
| Happy to chat more about my experiences with this strategy,
| davedx@gmail.com (I'm in Europe too)
| nadis wrote:
| +1 to this take. I think hiring a CTO at the start might lead
| to its own distinct challenges, especially if that's not
| something familiar. Hiring a small excellent team of builders
| could be an effective solution, especially folks with
| sufficient experience and very strong communication skills.
| lastofthemojito wrote:
| Agree with the general approach, whether the devs are
| contractors or employees. In my industry we might call this a
| Skunk Works project. Get a small, talented team and turn them
| loose on a focused problem. If they make fantastic progress,
| great, if not, at least it wasn't a huge expenditure.
| alberth wrote:
| Genuine question: how do you suggest for that code to be
| maintained long-term if the original team was just freelancers?
| ragebol wrote:
| Code is often written for an audience: yourself on a year,
| maybe a younger team member you have In mind. Knowing you
| won't be around to explain can help drive some decisions and
| write docs for the audience.
| j45 wrote:
| It's can be less about code and more about supporting the
| evolution of the business process.
| henryfjordan wrote:
| If you do go this freelancer route I would assume that there
| will be no code to maintain long-term. The freelancers should
| be building a prototype, not something intended to last
| decades.
|
| Either the freelancers work out and you begin hiring a
| permanent team (hopefully converting some freelancers to
| full-time) who will promptly rewrite / revise the prototype
| or you will go back to paying for software. Either way the
| prototype code should die or be taken over.
| kelnos wrote:
| Is it common to build a prototype to throw away, and then
| actually throw it away and build the "real" thing? I've
| never seen that, ever, in 20+ years of software work. The
| prototype ends up being the long-term production version,
| for all its faults and weaknesses.
| conductr wrote:
| Acknowledge and incent the exit plan from the beginning
|
| Incrementally, it might make sense to hire an independent
| audit on occasion. This might be hiring a senior to jump into
| the codebase for a week or two to see if they can make sense
| of it or see any glaring red flags. The important part is
| them knowing this will take place and them not knowing
| exactly when or by whom.
| maccard wrote:
| Consider where the company is right now - they're entirely
| reliant on a third party product that doesn't suit their
| needs. Every codebase is maintainable (to a certain extent),
| and the first step in getting a long term maintainable code
| base is... getting a code base.
|
| Freelancers don't inherently write better or worse code than
| FTE's. Some of the most braindead, unreadable, undefendable
| code I've seen has been written by FTE's while contractors
| are leaving them in their dust.
| christophilus wrote:
| Agreed. The important thing is the senior part. Find and pay
| the hefty premium for a small, experienced team. The code
| quality questions, etc are answered by that.
| poeticsilence wrote:
| Strongly agree here. It's hard to find a CTO if you don't have
| access to any engineering talent that you trust and have
| vetted. A small, focused project with a team of very senior
| freelancers both gives you a chance to dip your toes into the
| idea of running your own in-house software development, and an
| opportunity to vet individuals who can help you make good
| hiring decisions down the road.
|
| If you're interested in following this strategy, don't hesitate
| to reach out to poetic.artifice@gmail.com -- I'd be happy to
| help on both fronts.
|
| As for your concern about logistics being not sexy enough -
| I've found that the best programmers (and the ones you'd want)
| are more interested in the technical aspects of the problem and
| business and customer impact, rather than the sexiness of the
| business domain.
| kelnos wrote:
| > _I 've found that the best programmers (and the ones you'd
| want) are more interested in the technical aspects of the
| problem and business and customer impact, rather than the
| sexiness of the business domain._
|
| Just want to heartily agree with this point here. Certainly
| many of us _do_ get excited about particular business domains
| from time to time, but in my own experience, I get more
| excited about technical challenges, and -- critically --
| solving real problems for real customers that I can see
| first- or nearly-first-hand. The customers for this
| "product" would be internal to OP's org, so the people who
| end up building this would have front-row seats to how it's
| being used, what's good, what's bad, etc.
| j45 wrote:
| As a developer who became this kind of a CTO a decade, maybe
| two before it became fashionable, I would have agreed with this
| in the past until I learned why otherwise with companies this
| size.
|
| All the devs in this comments can do what I share below. 1000%.
| It's a different way to make an impact and help make healthier
| spaces for technical teams to do what they want.
|
| I'll share one example. Clever architecture and leverage can
| beat most coding especially in the B2B space. I find I am fast
| at both architecting and uncovering useful system integration
| paths for the short and long term along with the flexibility in
| mind.
|
| That being said, I have also seen a team of 100 devs flown in
| to write an ERP from scratch and it worked too because the
| process was fixed.
|
| I won't rule out a world beating team where 5-10 senior devs
| can beat a team of 50-100. I have got to be a part of those
| kinds of teams and also lead them. The caveat is being able to
| deliver world beating stuff is different than aspiring to it as
| well. It's just not always sustainable way to live.
|
| Since A company usually sells to companies the same size or
| larger. Anyone who comes from scratch can have their goose
| cooked pretty quick when a new client demand a different level
| of scrutiny in systems and data if coding from scratch.
|
| Having deep enough experience to poke my head out in this
| thread both on my own as IC leading the charge, or or taking in
| my team, the orchestration of internal and third party vendors
| and resources is a big part of this. I deeply believe in
| external vendors operating in a client side platform I help
| implement and leave them with training that works.
|
| A technically functional CTO who is still technical en putty to
| simplify and leverage to help deliver impact helps bring in
| different kinds of architectural and framework approaches.
|
| I loving call it what management consultants talk about it
| don't do. I've made learning and implementing that my craft to
| leverage solutions for anyone I put my time towards. It's a
| life changer. Everyone wants the kinds of devs on YC to help
| their companies if they can learn a little bit of business.
|
| It works well enough that I don't need to pursue a public
| profile (although that is not changing), and warm introductions
| are a reality.
|
| I share this because it's possible for anyone who wants it
| instead of downplaying it. I help clear the path for the doers
| and builders, as one.
|
| You have a fair indirect point that there's a lot of different
| kinds of CTOs too.
|
| If a business wants steady operation while switching over it
| will ultimately place a heavier loads on their teams.
|
| If a business wants capacity to operate more smoothly to either
| grow capacity or increase flexibility for other things with
| their existing workforce.
|
| This kind of thing may not always be built to success with the
| number of surprises and landmines discovered along the way.
|
| Part of a transformation can become agile, parts of it water
| fall, all while holding the business and staff increasingly
| hostage while deciding to do a big bang switch over or daring
| to run in parallel.
|
| Lots of people side things come up as well when changes happens
| to them instead of with them. It's not uncommon for subject
| matter experts choose not to share information what itself can
| take some time.
| cvladan wrote:
| OMG. GPT? Claude?
| heisenbit wrote:
| Having had the fun of taking over a project from a bunch of
| clever contractors I would caution: It may be too clever. There
| is value in simplicity and a stake in long term ownership. Some
| article here recently associated technical debt as lost
| institutional knowledge so handing the most key decisions to
| contractors has also drawbacks. One needs an integrated
| approach for design, build, maintenance and operation.
| cellularmitosis wrote:
| Mixed in with this may also be architectural decisions based
| from a "let's just spin something up quickly" mentality.
| Those foundational architectural decisions have a way of
| becoming set in stone, long after the freelancers have left,
| dooming the project to scalability and latency problems which
| seem to linger forever.
| treprinum wrote:
| Good freelancers are expensive and don't stick around long-
| term.
| kelnos wrote:
| That's fine; this would be an experiment, after all. If it
| goes well, those freelancers can be tasked to help hire a
| more permanent team, and/or be offered permanent positions,
| if they're interested.
| jonahbenton wrote:
| Yup. My consultancy is this- collective of very senior folks
| who have worked together for years, with experience in most
| business domains, most tech stacks, and most compliance
| regimes. This is what we do- accelerate the transition from
| either internal legacy or external dependency onto new solidly
| architected appropriate/ergonomic stack for internal team to
| maintain/extend. You can't hire the experience to get you
| started in the right way. We leave once you are transitioned
| because you don't need to pay premium to operate. Feel free
| also to reach out, email in profile.
| alemanek wrote:
| This is excellent advice but I would back up a few steps and do
| a few things before bringing in a freelancer team.
|
| Identify a part of this system that can work somewhat in
| isolation and is non-critical if at all possible. Then document
| the requirements for this part thoroughly. This allows you to:
|
| - Have something smaller for your new team to cut their teeth
| on.
|
| - Ensure you have collected all the diffuse domain knowledge
| for this part in one place in the form of structured
| requirements.
|
| - Forces you to think in terms of what you need and what is
| acceptable delivery,
|
| If need be you can bring in a Senior/Staff level engineer to
| help you through this discovery and definition phase.
|
| In my experience the most common difference between success and
| failure for a project often comes down to clear requirements
| and expectations. Your employees are the domain experts. You
| need to collect that expertise and document it in a way that
| this team can reasonably consume. This is difficult and time
| consuming so start now.
|
| They will still have questions and get things wrong but this
| gives you a roadmap. They are going to be learning your
| industry while you are learning how to build software.
|
| Best of luck
|
| EDIT: formatting
| foxtacles wrote:
| Agree with this advice. Our consulting agency, also based in
| Europe, specializes in exactly this - bootstrapping software
| solutions for companies that lack the in-house experience to do
| so. After a successful launch our clients usually transition to
| hiring employees to take over our work - a transition we
| actively support. It works out quite well in our experience.
| (contact/website is in my profile if interested)
| JoachimSchipper wrote:
| One pitfall to consider: software development is often its own
| culture, and nourishing and valuing (or merging!) multiple
| distinct cultures in a company requires real effort from
| leadership/management/team leads/senior ICs/...
|
| I'm sure that e.g. truck drivers and software developers can be
| _made_ into a strong team, but don 't just assume that cross-
| culture collaboration will work "by accident"/"automatically".
| pbronez wrote:
| Concur. In house can work wonderfully, but you have to get the
| dev team integrated into the soul of the business... and you
| have to be willing to bend when they tell you the current
| system is insane.
| novia wrote:
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| Yes. There's overlap between transit nerds and software devs. I'm
| one example.
| hyperpape wrote:
| What you don't say is what the product is, what you spend on it,
| and what its value is to your organization.
|
| I'm in the software side of logistics, and I can imagine very
| different things you could be referring to, with different levels
| of effort and different levels of benefit/risk to you.
|
| If it's just cost-savings, then this product has to be quite
| expensive to justify your time. If you're hoping that a better
| version of this product could make your operation more reliable
| and efficient or unlock new business opportunities, that's a much
| better proposition, though still hard.
| jppope wrote:
| Weird way to approach this... since its a critical business
| decision, wouldn't you like a formal professional opinion? Seems
| like it would be worth the $500/hr for a week to get real
| information that you can use to get a decent view of what your
| options are...
| ckrodrigues wrote:
| Hey! We also went through the some process, and in the logistics
| space. We ended up developing a solution in house. Because we
| fully understood the problem we were able to build the best
| product for us at the time, but it did took considerable
| investment from the company (and while the product was great,
| still questionable if it was the right investment to make). On my
| side specifically: I ended finding that what we built could be
| generalized for similar verticals, and now we have a SaaS product
| based on what we had built internally.
| RangerScience wrote:
| My two cents:
|
| You have a greenfield development project with a _very_ well
| understood set of business needs and requirements, and you have
| the budget (I 'm guessing) to run some small-scale experiments
| _without_ the usual sort of time pressures; to a certain kind of
| developer (hi!) this is _super_ attractive.
|
| I would spend a few weeks getting to know big chunks of the core
| use cases, and then architect a system designed from the
| beginning to handle those needs, and the prototype a bunch of
| that system over a couple of months.
|
| Although these time estimates are totally armchair bullshit, what
| I'd _actually_ do is timebox both steps to something like "two
| weeks" and "two months" - that'll help mitigate scope creep
| that'll come from not having the usual sort of time pressure.
| It's not about getting it done, it's about finding out what it
| would take to get it done, and seeing how much can be
| accomplished in a set amount of time is a good way to do that.
|
| The key bit in all cases is (1) hiring good people (2) _getting
| out of their way_ except for (3) keeping them on track. (One
| trick for #3 is to have them propose plans, and then always ask
| "okay but is there a simpler way to do it?", 2-3 times, kinda
| like 5-why's).
|
| For #1, I'd look at talks people give at conferences, and then
| either try to hire those people, or ask those people for
| referrals.
|
| For #2, that's your executive-level corporate culture.
| Unfortunately, from what I've seen, you either already have it or
| you don't, and that's probably not something you can change
| _because_ if you don 't have it, you also don't have the
| psychological safety necessary to _find out_ that you don 't have
| it - although, you can look for where you've got high employee
| churn, and that's where your problems are.
|
| For #3, I'd use a combination of what I call the "wine trick"
| with "ELI5". The "wine trick" is that you don't actually need to
| know anything about wine to find out if someone else does: just
| get them talking about the details of their special interest, and
| if they _can_ , they know a lot about their subject. Combine that
| with "Explain It Like I'm Five" to find out if they're actually
| just bullshitting, and because the _other_ way to find out if
| someone knows a lot about something is if they can teach it.
| (Plus, they 'd need those communication skills during the rest of
| this process anyway).
| j45 wrote:
| Hello,
|
| I've only done B2B transformations (revisiting all software
| systems and realigning/reimplementing them in parallel) like this
| in multiple verticals, both physical and digital, for the past 20
| years as a Fractional CTO for companies in your revenue range and
| larger.
|
| As needed I can traverse the entire pyramid from top to bottom
| from business strategy, finding partners and vendors, and
| informing everything down to the nuts and bolts alone for maximum
| alignment, and ensure it's learned alongside team members in the
| organization.
|
| I often help with the budgeting and estimating process and find
| customers save significant time and money with the right
| strategy, approach and oversight.
|
| Here's my take:
|
| 1. ATTRACTING TECH TALENT:
|
| - Consider a contract-to-employment model. I've built teams where
| contractors who prefer employee life can switch over. There's
| other options too depending on your current mix and structure.
|
| - Emphasize training at all steps. I guarantee clients a trained
| and productive resource, regardless of employee or contractor
| status.
|
| 2. THIRD-PARTY TO IN-HOUSE TRANSITION:
|
| - Success: Helped clients reduce days-to-cash by 50% with custom
| solutions, projects relatively on time, and staff that remained
| able to work in the new system.
|
| - Caution: Seen projects stall due to underestimated complexity,
| or avoiding realities (ie., data may not be as good as they
| thought)
|
| - Run fast from anyone who wants to build only code from scratch
| from the outset. Also run from buying an all-in-one system until
| you know what your critical path is. I have worked around and
| through both, including from the start, and rescuing projects.
|
| 3. POTENTIAL PITFALLS:
|
| - Underestimating current system complexity.
|
| - Cloud lock-in: It's the new software/vendor lock-in, just
| sneakier. There are ways to have your cloud cake and eat it too
| while maintaining options.
|
| - Over-engineering: Build software has become horribly
| overcomplicated. It's hard to keep things simple and flexible,
| easy to make it complicated. Helping everyone understand the data
| and process together sheds a major light on the path ahead and
| create a better sense of ownership.
|
| 4. ALTERNATIVE SOLUTIONS:
|
| - Hybrid approach: Develop core competencies in-house while using
| strategic third-party solutions.
|
| - Agency acquisition: I've facilitated M&A deals where companies
| purchase agencies.
|
| - Vendor-as-internal-department: Set up external vendors with
| internal SLAs.
|
| KEY CONSIDERATIONS:
|
| - I would start with an honest assessment of where your
| organization truly is and where it wants to be. Beyond advisory
| or building, learning where your business needs to head and
| measurable ways to get there is critical.
|
| - In-house dependency is important, but there may be better
| external options too that can be much more stable than an agency
| with interests with multiple clients.
|
| - Any culture change and planning for it is critical.
|
| - Industry standards (SOC, HIPAA, etc.) and architecture will
| ultimately decide the fate in 5-10 years.
|
| - I keep software sales promises honest and accurate to the
| company, ensuring clarity on current state and future direction.
| Includes negotiating contracts that work for the business, not
| the vendor alone.
|
| I have a lot of conviction about what I do because I've done it
| and still do it, keeping up with where things are headed to
| provide input on where things could be. I train to process, and
| so the process is central.
|
| If you'd like to chat more, I'm happy to offer an hour of my
| time.
|
| I'm genuinely curious to see how much actual valuable information
| and insight I can provide to help you think through your
| situation. Firehose, or key points. My email is in my profile or
| reachj45@gmail.com
|
| My goal is to give you as much food for thought as you like,
| knowledge as possible, regardless of any direction you ultimately
| take. My email is in my profile if you're interested in a no-
| strings-attached discussion, except I'd like you to bring the
| most painful issues.
|
| The world is an odd place where people who don't understand
| software sell it to people who don't always know how to buy it,
| let alone roll it out. Navigating this can be an outlier for
| impact. I'm here to help change that where it crosses my path and
| get technology working for people instead of the other way
| around.
|
| Note: Edited from a laptop instead of written from a phone. :)
|
| In case anyone's thinking of reaching out, offer is open to
| anyone relative to my availability.
| angrymouse wrote:
| Right in the middle of a retiring of a big external platform and
| moving it over, slice by slice into separate company owned
| products and APIs (and a few off the shelf things mixed in too!)
|
| I think there's plenty of sensible advice about getting a
| technical person with experience and expertise to help make the
| right decision. Between doing it yourself, building a platform
| with various tools stitched together to finding ways of getting
| what you need from existing suppliers and other tooling.
|
| Something I would also suggest is to be really clear right now on
| how you currently work, how your existing platform works and the
| problems it's causing or at least the opportunities you feel
| you're missing out on.
|
| To do this suggest getting a "discovery" team together and doing
| some service design and analysis to map out your user flows,
| business and tech. The as-is. and laying against that all the
| pain points and missed opportunities.
|
| Then using the same team to help you craft how it _should_ work.
| The to-be vision.
|
| Then using that to-be vision and the insight and expertise you've
| developed to help you decide how best to get to that to-be
| vision. As cheaply and sustainably as possible.
|
| Part of the organisation I'm helping out. There's a vast
| difference between the parts where that discovery work was done
| (and done with clear purpose) and the bits that haven't been
| done. And the endless delay and struggle they've had.
| PeterStuer wrote:
| One thing I did not see discussed here which in my experience as
| an outside consultant for significant bespoke software
| developments was important:
|
| Yes, you can attract and retain a good core development team
| through extrinsic benefits like nice salaries, bonusses, company
| cars etc. even if your business is not considered intrinsically
| attractive. However, how will the rest of your employees, both
| workers but also management cope with people in essentially
| purely production roles potentially be significantly more
| compensated than your middle management?
|
| I have seen more than one client that in theory could have
| benefitted from an inhouse team, but where that was the
| dealbreaking issue.
| shulu wrote:
| Having built one of the largest tech-enabled 3PLs from ground up
| and serving as CTO for a logistics tech startup with client 20M -
| 1B annual transportation spend, my take below
|
| > We're using a third-party product that functions, but barely.
| The provider is understaffed and unresponsive and the platform is
| stagnant. It's a fight getting basic bugs fixed let alone new
| features implemented. We're having to resort to a separate low-
| code platform to fill in the gaps. Our business operates in a
| specific niche and there are no other providers who cater
| specifically to our industry.
|
| Most successful and agile 3PL and LSP (non VC backed) do not
| build all their tech, but rather glue tech together. They
| leverage pre-built TMS, WMS, YMS and build out in-house
| middleware layer for analytics and control points. Key is to
| guarantee portability of data and analytics with a unified view
| of the business.
|
| > On the other hand, while our current solution seems like a
| straightforward CRUD app, I fear the devil is in the details.
| Will we get stuck at 80% completion? We do a lot of data exchange
| via EDIFACT, for instance, with various government institutions
| all over Europe. This feels like a quagmire in which development
| can quickly stall.
|
| The Devil is definitely in the details. We regularly ignore what
| C/VP/Dir-level's description of tech and business process.
| Talking with the direct team member or their manager reveal so
| much more of the real painpoints than what higher up learns. The
| risk here is not business adopting tech but rather tech team
| understanding business. Have a senior leader here who are
| technical with strong business domain expertise is critical. They
| need to form a culture of domain understanding throughout the
| tech org.
|
| > Strategies for attracting and retaining tech talent in a non-
| tech industry Experiences transitioning from third-party to in-
| house software (success stories and cautionary tales).
|
| It is very hard. Mostly due to comp, EPD treated as a cost center
| (and engineers do not want to be devs), lack of recognition of
| the industry.
|
| There is one thing going for logistics, it touches physical world
| and is extremely complex (not hard). It attracts certain types of
| people prefer complex problems. Aside from senior tech leaders
| and a few senior engineers, you will be aiming for the diamond in
| the rough profile here.
|
| There are rare cases such as Ryder acquiring Baton and use the
| latter as their core Engineering while keeping some old IT groups
| hanging around. Ryder is large enough to pay tens of engineers
| 300k+ salaries.
|
| > Potential pitfalls we might not be considering. Alternative
| solutions we should explore.
|
| Instead of building a tech team to build everything, you have an
| artifact, who is a domain expert on your own business, define a
| business middleware and analytics ingress for the company. Start
| by normalizing against the middleware and analytics ingress with
| consultants before building your own tech team.
|
| Logistics has been the most fascinating industry I have worked in
| and I see my whole career in this industry. Excited to chat more
| tech strategy in logistics, email shu at loop dot com.
| hekker wrote:
| Shoot me a message, I am VP of Engineering at large European
| software logistics company, where I had exactly the same
| challenge (outsource vs insource). Email is in my profile.
| groby_b wrote:
| You said EDIFACT - it'll cost more than you expect :)
|
| You'll need to attract folks who care deeply about the space
| (yes, they exist, for some people logistics is fun), are seasoned
| software devs (the pool shrinks) and set them loose on the
| problem with as few restraints as possible.
|
| Your best bet here is an approach that gives them a stake as
| well. Either as an external experiment with performance gates, or
| by founding a subsidiary that they co-own, or ... well, any
| number of solutions.
|
| Yes, you won't be able to outcompete FAANG on salary, but you can
| outcompete them on autonomy. And a lot of experienced devs care
| about the latter part more. (Having made and saved a good chunk
| of big tech money)
|
| Biggest issue will be vetting the people you find. If you don't
| have inhouse experience, either take an approach like davedx
| suggested, or reach out to somebody who has (hekker)
| brink wrote:
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| I've been building advanced web apps for 14 years, and I'd
| happily spear-head something like this, especially for a field as
| "non-glamorous" as logistics. And I have a feeling there are many
| developers out there like me.
| smilliken wrote:
| Consider acquiring the vendor. Give them a heads up that you're
| considering building in house and you'll at least get better
| service in the meantime. Make sure their leadership gets the
| message.
|
| If your business is growing and this is an important part of the
| business, then you'll eventually regret not building in-house. Of
| course, you may regret poor execution on the in-house solution,
| but the response to that is to start small and incrementally grow
| scope instead of trying to switch over a big mission-critical
| system. All big functional systems start as small functional
| systems and grow incrementally. It's easy to imagine the system
| you'd like to end up with, it's hard to imagine a series of small
| changes to get there from where you are. But if you want it to be
| successful, you have to take the longer path that is in
| production the whole way through.
|
| Consider having the new development focus on features you don't
| have in the current vendor solution instead of replacing features
| you already have. These will be more impactful and give the new
| team some positive inertia.
| milesward wrote:
| Seems like a good fit for a development contractor/consultancy:
| get pros to try to gin up a v1 clone fast. If they show that it's
| not too bad, no gnarly gotchas, have them help you hire folks who
| can get to v2 and beyond. Starting a software dev practice is
| _daunting_ without prior applied experience, use the cheat code.
| mindcrime wrote:
| _Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?_
|
| Yes. This is a complete non-issue. Plenty of developers work for
| companies that aren't "glamorous / sexy tech companies." In fact,
| I'd almost be willing to bet that - in aggregate - _more_
| developers work for companies like yours than work for those
| glamorous tech companies. Consider - every auto manufacturer,
| auto parts chain, soda-pop manufacturer, supplier of sheet metal,
| supplier of PVC pipe, sewer construction company, insurance
| company, retail chain, yadda, yadda, yadda, has IT staff. OK,
| excluding maybe some really small firms who also outsource to a
| service provider of some sort. But I think you get the point -
| using and developing tech isn 't something that is only done by
| "tech companies".
|
| Offer good pay, good work life balance and private offices for
| developers (if working in the office) and/or a healthy approach
| to remote work, and finding developers shouldn't be a problem.
| HeyLaughingBoy wrote:
| Last time I looked 80% of developers were building software for
| in-house use.
| 91bananas wrote:
| I work on an internal team like you would be building, I think
| for a company of your size and probably needs it is very much a
| needed thing to control the software in-house. Not having people
| that are dedicated and know your stuff leads to the situation
| you're in. Just do it. We've outsourced a couple small projects,
| then re-written them within our team because the quality and lack
| of specification is just...bad.
|
| My current industry is pumping chemicals, it's non-glamorous but
| it's a need that must be fed, versus "fancy tech" or whatever. We
| keep a team of guys employed and happy. Just pay them decently
| well, don't try to micromanage them, give them good requirements
| and honest feedback, give them the tools they need.
| deanebarker wrote:
| Incidentally, "Domain Driven Design" was written around a
| theoretical logistics/shipping platform. That book didn't make it
| seem "non-glamorous." Everything is exciting to someone.
| architectfwd wrote:
| I'll caveat my response here: this is provided as general
| guidance and should be seen as such.
|
| 1. Have you considered managing your providers performance? What
| could you do in this area?
|
| 2. Have you considered going to market for other providers to
| start new or to take the solution over? Is that even feasible?
|
| 3. Have you considered the long term capability build you need in
| your company if you decide to bring this in?
| huijzer wrote:
| I have not navigated a similar transition, but I have studied CS
| and read tons of business books.
|
| I think if you do this and take the development seriously, it
| will be a ridiculous good return on investment. The success to
| Tencent according Mohnish Pabrai was that they had ROI on their
| developers over 10 years. They just put everything they could in
| development and if it was too much they would spend the rest on
| lower ROI categories. Overall 50% ROI. (IIRC).
|
| It's also essentially vertical integration if you do this. If you
| think it can make your beer taste nicer, as Jeff Bezos put it,
| then it's probably worth it. Note that Amazon's in-house team
| spawned a new industry. Also, Tesla is currently much ahead on
| competitors due to their software. I think many car manufacturers
| underestimate how much Tesla is ahead. The apparently even have
| their own ERP system called Tesla OS.
|
| For attracting and retaining, I think you can definitely do it.
| There are engineers who like to see physically how their product
| is being used. Short feedback cycles can be very rewarding. Also,
| to retain I would look at Napoleon. What is the best for morale?
| Winning. Give ambitious projects and make them succeed.
| ragebol wrote:
| Is acquiring the third party software provider an option? And
| then staff them with a few more ppl maybe.
| alberth wrote:
| No advice per se, but questions you'll want to consider as you
| read others posts:
|
| 1. why do you believe you can build it better? (even with the
| most amazing team)
|
| 2a. its easy to over-estimate the gains of a rewrite, and
| dramatically under-estimate the negatives. how bad could things
| get, for the business, if you migrated to a _worse_ solution?
| (lost revenue, lost customers, etc)
|
| 2b. after you answer #2a, do the gains (of a rewrite) now really
| seem so big?
|
| 3. if you outsource this rewrite to a 3rd party (freelance,
| contractor, etc) - how is that any different than today? you're
| already "outsourcing" this to an existing vendor. How would you
| maintain code from non-employees?
|
| 4. can the business even support the cost (and it's a positive
| cost/benefit analysis) on hiring full-time employees to rewrite
| and maintain this code base - forever.
|
| 5a. what do your competitors do? (buy the same vendor software or
| they built their own)
|
| 5b. if they use the same 3rd party vendor, is the market big
| enough for you to turn this into a new revenue generating
| business (sell this in-house app you'd build)?
| MattOfNZ wrote:
| I worked on freight and logistics software for 10+ years for a
| New Zealand based company that has significant operations in USA,
| Australia, Europe and Asia. (domestic freight/road, air, sea,
| 3PL)
|
| We were a bespoke software dev shop, and the freight company was
| our customer.
|
| During my time there we were transitioning to their third "major"
| version of the software over about 30 years. It was a new system
| designed to handle the US market, where the customer was a
| relatively new entrant who had been running off the shelf
| software for some time.
|
| Due to the way they run their business, with strong P+L
| requirements down to each individual location/site they had a
| presence, and even individual trucks operating as separate
| business units, a lot of what got built was effectively
| accounting. If this sounds like you, or you use a lot of third
| party carriers, keep this in mind: tracking freight movements
| alone isn't that hard, but you need really strong accounting
| fundamentals in the system from the get-go to be able to really
| understand costs in this business. Some off the shelf software
| doesn't do this particularly well.
|
| Based on this - my strongest advice would be to choose boring
| tech (Java or .NET) and recruit specifically for some core
| developers who have a solid grounding in accounting fundamentals,
| or do some serious training on this before embarking on the
| design. You will inevitably end up posting journal entries to
| your accounting software, so treat cost tracking as a double
| entry accounting system rather than trying to construct a journal
| as an output.
|
| The customer is pretty vocal in their annual reports (publicly
| available as they're listed) about their successes in IT as well
| as their business model. They look at having control of their
| platform "in house" (product ownership in house, outsourced
| development of their own platform) as a core part of their
| success.
|
| If you would like to chat, I'm not hard to find - look me up on
| GitHub, then search my name + New Zealand on Linked In. (My
| customer is also pretty obvious from there).
| jasonteunissen wrote:
| Hi Matt of NZ We are currently setting up logistics SAAS
| specifically for NZ crane and hiabs, and will later branch out
| to other industries and countries. we are MotherTrucking.co.nz
| find us, and let's have a talk, you sound like someone we
| should get to know.
| pphysch wrote:
| Invest in high quality software kernels and professionals that
| can comfortable build with them; divest from low-quality
| "wrappers" around said kernels, which is most SaaS.
|
| >90% of SaaS are some (expensive, low-quality) wrapper around
| (free, high-quality) Node/Rails/Django/Spring + a FOSS RDBMS,
| with more features than you want and less than you need.
| eamag wrote:
| Can someone explain me how this post works? I see here it's 5
| hours old, but when I go to the OP profile it says it's 3 days
| old https://news.ycombinator.com/submitted?id=45HCPW
| fragmede wrote:
| second chance pool
|
| https://news.ycombinator.com/item?id=26998308
| tpm wrote:
| If you go down this route, try to hire someone from your provider
| that knows the current product well from the inside. If there is
| someone left, of course.
|
| At a previous company, when the provider of our software started
| stagnating, we brought the development inhouse by hiring his best
| engineer and a few good freelancers, then slowly phased them out
| in favor of employees. But an important difference was we owned
| the code because it was a bespoke solution from the start.
| KaiserPro wrote:
| My advice would be: Specs specs specs.
|
| If you're going in house, or buying in a consultant, you need to
| be sure about functionality and why you want it. That way you can
| draw up small, medium and long term goals for what you _need_ and
| how it affects the business.
|
| The risk with inhouse (or contractors) is that the devs get
| bogged down in what tool rather than how to solve the business
| problem.
|
| make sure you have a good idea about the processes the software
| is supposed to handle, and what data you need for that.
| pipesorter wrote:
| Like others mentioned get a freelancer or an external team for
| starters. Engage them for 2 weeks. I run a dev agency. I recently
| made a chrome extension for a customer for the first time and it
| just took us 2 days instead of 2 weeks because we leveraged
| claude sonnet. So building a software today is incredibly easy,
| you can build almost anything at an incredible faster rate. So if
| you set 2 weeks engagement and you can see how much is done, you
| will know how to work with the person and team and also will be
| confident in your plan to move away from the software you're
| using. You could then have this team or freelancer document how
| this is setup etc and you can slowly start hiring in house. For
| eg, it costs like 800 USD for two weeks in our case since we are
| based out of India, so when you outsource to India, Vietnam etc
| you have low risk, you can quickly experiment instead of
| contemplating.
| HeyLaughingBoy wrote:
| Building software in two weeks?
|
| It would probably take more than two weeks just to understand
| their business enough to be able to get your mind around what
| they need.
| Satam wrote:
| Maybe the limitations of the software arise from the fact that
| it's being sold at a price that's relatively too low? It sounds
| like it's very niche software with only a handful of users like
| you at most. With a small number of paying users, even if each
| one is paying thousands per month, the tool's team might be too
| underfunded for it to do much more than maintenance.
|
| To do it in-house, you'll probably hire 2-3 engineers. You'll aim
| to have smart people who can self-manage, design, and who can
| intuit the business requirements. Your part-time duty will become
| to be the product's "CEO" of that whole thing.
|
| So you'll end up paying at least EUR16000/mo (3xEUR6000) in
| salaries alone. Data access, storage and infrastructure will
| probably cost a bit too. How much are you spending now?
| silisili wrote:
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics
|
| Money! Work life balance. Good benefits.
|
| I currently have zero interest in the business idea of the place
| I work. But they pay well, aren't on my ass if I wake up late or
| need to visit a doctor appointment, and provide zero cost
| benefits. I have no interest in making even more money or trying
| to climb. Take care of your people and the business line doesn't
| matter. Just make sure you get what you're paying for.
| gwbas1c wrote:
| The best developers I've worked with, in my career, were all from
| contracting firms. (Distillery, Ralabs, EPAM.)
|
| First thing: If you outright fire your contracting firm, you'll
| loose all of their knowledge. This could harm your company more
| than you realize, depending on how much your business relies on
| their knowledge of the code and your processes.
|
| What I would do is have some employees who work for you, who are
| experts and "in charge." They should be experienced in hiring and
| screening, and should be able to give you an honest assessment of
| your code base's maintainability.
|
| At that point you can decide, with your expert employees, how
| much to outsource with your current firm, how much to outsource
| with a new firm, how much to insource, and most importantly,
| _what you are doing wrong in your relationship with your
| developers_.
|
| The thing is, software development can fail for many reasons, and
| a lot of them have more to do with you than your vendor. You
| might have unrealistic expectations, you might need to work more
| closely with your contractors, or your contractors might be "warm
| bodies punching a clock." It's hard to know unless you have
| people you can trust hands-on.
| AAL_throwaway wrote:
| I've faced a similar situation as an exec in a different field.
| Some questions consider:
|
| 1. Are you trying to replace the system-of-record? I don't think
| it changes the technical merits of going in-house, but it does
| raise the stakes. It becomes more important to engage other
| stakeholders, and to prepare the business processes/workflow for
| changes. Secondly, there will be a transitional period where you
| will need to use both systems, so you will need to have a way to
| reconcile and merge conflicting records from both systems into a
| single source-of-truth. Again, these are not deal-breakers, but
| just things to think through.
|
| 2. How many integrations do you have with external parties? You
| mentioned EDIFACT and government institutions. Integrations are
| often the dominant source of project delays and complexity.
|
| 3. Management structure - you can hire someone to run the
| program, but like it or not, you are the corporate sponsor. It's
| success or failure will fall on your head. Whether you hire a
| "CTO" depends on your technical management ability, but I'd stay
| pretty close and pretty involved.
|
| 4. Attracting talent - as always, it's a question of money and
| time. You need a healthy budget for a healthy amount of time. A
| good, experienced senior dev consultant will generally have a lot
| of contacts, and can pull in others if you provide a solid
| environment, budget, and roadmap. I wouldn't be worried about not
| being in a "glamorous" industry - the people you want won't care
| about that. Some kind of equity or performance-based bonus can
| really motivate people to deliver value to the business.
|
| 5. Roadmap - take a vertical of the business that is more stand-
| alone and start there. You want to show an end-to-end in-house
| solution that solves a real problem. It will help you diagnose
| exactly what kind of challenges, culturally, organizationally,
| technically, (and even legal/compliance) that you have to deal
| with. It will be a confidence booster to the rest of the
| organization that this can work and will be successful. Adjust
| expectations and timelines as needed.
|
| Would be happy to discuss more, just DM me.
| winterbloom wrote:
| I'm an NA-based freelancer actually looking for work. I've got
| team-lead experience to take this in-house; Got contact info
| listed somewhere?
| thnetcoder wrote:
| I've done this at the CTO level in a non glamorous industry
| (construction). We spent about 3 months understanding the
| business top to bottom before building the software. We then took
| the best of the SaaS software that wasn't flexible enough and
| layered on what was needed with an eye towards massive growth.
| There's no way it would have ever got done correctly and be as
| stable/maintainable as it is now without that time up front. As
| others have said, you need someone who is vested in the business.
| Otherwise the dev team frankly won't care. You can't just throw
| some random devs at a problem like this one.
| HeyLaughingBoy wrote:
| There are other options.
|
| I've worked for Engineering Services companies and they excel at
| this kind of work. We'd interview you to understand your needs,
| quote a price to provide what you want and a schedule to get it
| done, along with maintenance as needed.
|
| Yes, I'm vastly oversimplifying to get the point across, but this
| might be a better model than trying to hire a single dev or
| create your own internal development team. I could only recommend
| doing that if you expected that your internal needs would grow
| continuously and that you could both feed your team enough work
| to keep them busy (and not wandering off into other jobs) and
| manage them well. Both of which can be far more difficult than it
| appears on the surface.
|
| You're not looking for an Accenture or IBM Global Services, but a
| small company, probably in your local city that provides custom
| development services. If you're in the US, I'll give Saturn
| Systems a plug: worked with their team before on a development
| project and I think this would be right up their alley.
| jvdongen wrote:
| My comment is made from the background of someone who has led the
| effort of bringing software development in-house, building a
| 20-odd FTE dev team, and is still leading it 3 years in.
|
| I'd not bring everything in-house at once unless you really have
| to. Your fear that the devil is in the details is very much
| justified (I have stories, boy, do I have stories ...). However,
| in your position I would definitively start building a dedicated
| tech team. That allows you to start developing real solutions to
| solve pain points in a way that feels less like "filling the
| gaps" and more like "the first steps towards a better future". It
| also may make you a better, more informed customer which may
| perhaps help with your current vendor as well. It also gives you
| something to fall back on if the proviable shit really hits the
| fan with your current vendor.
|
| Do not underestimate the importance of product management.
| Product management drives your development team. If you now use a
| basically off-the-shelf product, this is likely taken care of for
| you. Or not, given you describe the vendor as stagnant. In either
| case, you need to have that covered well.
|
| One-is-zero: do not rely on single individuals, build a team. At
| the leadership level you'd want at least a product lead, business
| analyst, cto and a senior software architect. Make sure they work
| together as a team and that there is healthy cross-over in
| expertise/experience so that people can cover for eachother. In-
| house, not contracted.
|
| I'd advice against fully outsourcing to an agency. You can
| contract a development team, and depending on where you are
| located that may be the most realistic option, especially in the
| beginning. But make sure you are at the steering wheel and have
| the people and experience in-house to use that wheel well (see
| previous point).
|
| Invest in boring things like documentation and testing right from
| the beginning. It will pay for itself many times over. If you let
| it slide, you'll never catch up and you'll pay for /that/ many
| times over.
|
| Other than that there's probably a lot I've learned from my
| adventure so far, but I find it typically difficult to assess
| what the lessons learned are unless someone pokes me with the
| right questions. Feel free to reach out at my HN username @
| mailbox.org.
| joatmon-snoo wrote:
| Were you at the company before they brought things in-house, or
| were you brought on for that job explicitly?
|
| I haven't been in this situation before, but I imagine one of
| the trickier challenges in a role like what OP is describing is
| that whoever leads this also needs the ability to manage scope
| for the team, including persuading the existing COO or whatnot
| that "yes, we _could_ bring this in-house but you really really
| do not want to."
| heisenbit wrote:
| Product management is really important and must not be
| delegated too far down. As main sponsor you need to be involved
| as well. A lot of key decisions must be made and ability and
| power to say no is vital as is the ability to move the other
| parties around your system at least a little once in a while.
| rsyring wrote:
| This is something you want to have an ongoing conversation about.
| With someone competent and experienced enough to ask the right
| questions. I can help you with that. Look me up and reach out if
| interested.
|
| Randy Syring, Chief Executive Developer, Level 12
| hahamrfunnyguy wrote:
| Since you can't find another vendor, it might be time to bring on
| software consulting practice that specializes in this area or at
| least doing something similar.
|
| If you can find a firm that is capable of doing the work, then
| you can figure out how you will maintain the software. You'd have
| to determine whether it would be better to engage that firm for
| the maintenance or hire someone. Possibly a combination of both.
| This could be done while the software is being built.
|
| Large software projects are more likely to take longer than
| estimated and go over budget, so be sure to factor this in to
| your calculations.
| fragmede wrote:
| Here's a thought: "just" buy the vendor.
|
| We don't have any of the details, but have you considered that?
| They already have the code to do what you want and know the
| problem space very well. Then your problems with them becomes a
| problem with themselves.
| rurp wrote:
| My biggest suggestion is to look into ways that the transition
| can be done in stages, rather than trying to replace everything
| in one big swoop. This is likely doable, especially since you are
| already having to rely on outside tools.
|
| Then to start building, hire a small team (employees or
| freelancers) and have them create a single piece of functionality
| that can be swapped out from the current workflow. This type of
| approach will limit the upfront costs and give you a much better
| idea of how feasible the replacement will be as a whole. It will
| almost certainly go smoother as well. Every rewrite/replacement
| of a large software project runs into a lot of unexpected
| challenges and complexity that will have to be ironed out, and
| this limits the disruption at any one time.
|
| There are a lot of factors in whether or not to go this route,
| but it's certainly plausible that it's a good decision. I worked
| for a smaller company that did something similar and gradually
| built out their own internal workflow software tailored to the
| business. Overall it worked out quite well and they ended up with
| much better software at a lower price than they would have paid
| for outside tools. I'm sure there are plenty of examples of the
| opposite result as well. You're right to be cautious but I think
| it's an idea worth exploring further.
| L-four wrote:
| This is my experience it's almost always better to continue
| working with the existing solution as you slowly replace it's
| features with your own until you no longer need it. The replace
| everything at once approached is fraught with risk.
| satya71 wrote:
| This seems like the story in "The Phoenix Project". If the
| outsourced software is critical to your operations, it seems it
| should be brought in-house. Software design is best done when the
| feedback loop is very tight. It never is with outsourced
| software.
|
| As for how to go about building a team, you are better placed
| than I am to figure it out. Probably start with a small team with
| the most critical bits and build from there.
| eqkRZX_wmv0jqp7 wrote:
| Get some experienced freelancers ( small team ) give them a proof
| of concept application to build. Review.
| FLT8 wrote:
| Reasons not to do this: - you don't really understand the full
| complexity of the domain or regulatory environment yourself - you
| don't have the funding available to commit to not only the
| development team but also the infrastructure to support them
| (tooling, cloud environments, security team, policies to support
| this, technical writer, ...) - you're not prepared to pay for top
| talent (assuming you can even judge it, see the point below).
| Starting something from scratch successfully requires a really
| experienced team who understand how to model and build things
| well. Who know how to build in sucha way that frequently changing
| things effectively become configuration rather than code etc etc.
| Most likely this means people who have 10+ years in the industry
| and preferably people with some product and industry experience.
| - you expect this will be a one-time cost hit and then
| effectively free in perpetuity; software is expensive to
| maintain, requires ongoing security patching, keeping up with
| library and technology updates, and ongoing commitment even if
| from a business perspective nothing is charging. - you don't have
| experts on hand who you can afford to have spending more of their
| time than you think is reasonable with your development team
| explaining in detail all of the lessons you've learnt from the
| current poorly performing software and what they really need. -
| you're not prepared for it to take at least four times as long
| and be four times as painful as even your worst-case initial
| estimates. - you're in an environment that requires eg. purchase
| of vendor libraries and/or integration to proprietary platforms
| and this impacts the economics of boutique development - you're
| highly regulated and software you build/use has additional
| complications like certification/audit/... requirements -
| especially if you don't fully understand or can't communicate
| this effectively to the build team - you don't know how to judge
| the competence or experience of your founding technical team;
| this will be critical to your success - more critical than almost
| anything else. One bad hire can derail your entire effort. - you
| want an entity that you're bound to contractually and that you
| can sue for remedy when things go really wrong. And they will go
| wrong. Of course there are lots of reasons to try to build the
| software yourself too, but hopefully the above gives a few
| counter points to think about.
| alcaide-mor wrote:
| If you have over $200M annual revenue, I can't see how you
| couldn't afford to build this thing in-house, but then I don't
| really know what kind of product we're talking about since it's
| so stealthy.
|
| When it comes to actual suggestions, from a developer's point of
| view I'd say the following:
|
| 1. Migrate slowly. Don't try to build an entire replacement for
| what you already have at one go. Tackle the low hanging fruits
| first. Plan the big replacement after the small replacements are
| already up and running.
|
| 2. You'll need at least one person to be the glue between
| business and tech, and that person must be developer-first, not
| business-first.
|
| 3. Don't overhire. You probably don't need a big team. I'm sure
| you'd be able to begin with no more than two or three developers.
|
| 4. Attracting talent should be easy since the job market has been
| terrible for developers. You can see job postings with thousands
| of applications.
|
| 5. Hire remote whenever possible. This will increase the talent
| pool enormously.
|
| 6. Always consider the possibility of SAASing whatever you'll
| build.
|
| Good luck.
| noduerme wrote:
| I work for a company in the decidedly not-sexy area of pet
| hospitality. We began building our own software when revenue was
| under $1M and we're now about 1/4th the size of your company and
| operate completely on our own software platform. The CEO of my
| company would convince you to at least try it in a heartbeat. As
| the original freelance developer and now the CTO, I'll give you
| the pros and cons from my perspective.
|
| For the first few years as a single shop, they used one then
| another suite of SaaS designed for the industry. These had some
| basic public-facing reservations website and a billing system
| tied to a database of customers, pets, vets, and calendar entries
| that employees could manage. But the owner was developing his own
| operational techniques in all areas of the business, with an eye
| toward building a franchising platform. Operational "secret
| sauce" he wanted to add in software included: How animals are
| separated and managed in groups, intelligent maximization of
| kennel space over time given inter-pet relationships (e.g.
| family, friend, enemy), tracking pet health and eating habits,
| matching employee schedules to volume, how reservation slots are
| filled or saved for most-loyal customers, rewards programs,
| seasonal rates, franchise-level business variables, getting
| customer feedback, daily photos and communication with customers,
| a mobile app for employees to track pets around the facilities in
| realtime, custom printed collars, projecting volume to fine-tune
| upcoming sale prices or peak rates, and on and on. It was
| difficult or impossible to get any features or even bug fixes
| from the SaaS developers.
|
| He hired me, as a lone freelancer, and paid me half of my
| estimate up front to spend a year writing him a software platform
| from scratch. Version 1 did all the basic things he was getting
| from the SaaS, and then we began iterating on all of the ideas
| and unique methods. It's been 15 years and one complete rewrite
| in a more modern language. The company has grown to 8 locations,
| managing roughly 200 pets per facility at any given time. I have
| - very rarely - brought on other developers to help, but
| basically the entire platform is easily manageable by one person
| and it's not even a full-time job. Our entire operating cost for
| servers, storage and backup is about $500/mo.
|
| Upsides: They can get pretty much any feature they want, built
| quickly and cheaply. I understand the business model inside out
| by now, so I'm able to quickly spot any potential operational or
| technical pitfalls in new ideas, and work with them to align the
| software to exactly what their _intentions are_ in new policies,
| as opposed to just following a feature spec. Just as a small
| example, when they changed their rules about deposit amounts and
| cancellation deadlines and fees a couple times over the years, it
| became much easier to write a subsystem that allowed them to
| manage those things themselves. Being so tailored, the software
| prevents employees from making common mistakes. Rollouts are VERY
| fast, sometimes in the same day as a minor feature is ordered up.
| We can make new versions available to one facility to test in
| production and see what bugs crop up, then roll out to the rest.
| Over time it has been more expensive than any SaaS, but at this
| point it would be impossible for the company to do what it does
| without the custom software. Owning the software has itself been
| a tremendous value addition for both investors and franchisees.
|
| Downsides: As my friends in the tech industry love to point out,
| all of this constitutes a lot of technical debt. If I die or
| something, they're gonna be pretty screwed for awhile. As it
| stands, it would take someone else awhile to come up to speed on
| the 500k LOC we have across 5 different apps in the suite. The
| software runs itself, it hasn't gone down in years, and it's
| recoverable if it does, but as far as bug fixes or new features
| or dealing with forced upgrades it would take awhile. It didn't
| have to be this way; they could have hired a team or transitioned
| to one. Given the CEO's outlook on building things himself, he
| would have built a team if he felt he needed to. Knowing what I
| know, they're lucky they chose me as a single point of failure
| and not someone who might decide to switch careers or retire
| early. But those are avoidable pitfalls.
|
| Final advice: Take time to choose well-supported technology
| stacks that will be around a long time. Documenting code. Most
| importantly, have your coder(s) work directly with the people
| responsible for writing and developing your operational /
| business procedures, and have them collaborate on writing the
| software manual. That way the logic of the business is understood
| by the coders and the logic of the software is understood by the
| people responsible for creating and implementing operations.
|
| It doesn't have to cost a fortune to get up and running and it's
| way, way cheaper than hiring an outside firm. Personally I love
| working for companies outside the tech industry who need in-house
| software, it's a much better culture and the results are
| immediate and tangible.
| empath75 wrote:
| You can first write software to work around shortcomings of the
| existing solution, and then gradually start replacing more and
| more of their functionality with stuff you've written in house.
| alentred wrote:
| There is a lot to consider given your situation and you have lots
| of input here already. So, I would only add my 2 cents in the
| case you finally decide to bring the dev in-house:
|
| 1. Start the team from hiring *senior* talent. Prefer
| *pragmatic*, experienced, and reasonably "passionate" (about
| technology) people. 2. As soon as the software team starts to
| grow, hire at least one experienced product design / business
| analyst.
|
| Initially, someone experienced from the logistics department
| could work together with few software engineers and explain the
| business. At this point you need experienced software engineers
| who would carefully here you out, understand and internalize your
| needs, and translate this understanding into software. These same
| engineers would also need to expose you to the *just right*
| amount of technical details, for you to make the informed
| decisions about the product. I dare to say that everything else
| *does not matter* in a sense that you should trust this core team
| to make the right decisions in the area of software development.
| Eventually, as the overall complexity grows - product growth,
| team growth, etc. - you would need dedicated people to fill in
| this "bridge" role. Initial core team will get tired a bit, will
| need to focus on other things, so they'd need some help to
| structure the product. It is not easy, this role exists for a
| reason. It is overall less efficient this way (as in "output per
| person"), but necessary for further growth.
|
| ---
|
| *Most importantly of all*. Have you considered buying an out-of-
| the-box solution? Do they really-really not work? Replacing
| something that already exists... I never saw it go as expected.
| mrwyndham wrote:
| IMHO I believe nearly every organisation I have worked with at
| this size always has a management problem.
|
| The reality is if you want your teams to be competitive adding
| contractors competing with your in-house staff can be a really
| good thing.
|
| Most in-house teams are jaded with management and having
| contractors set to do jobs (of course they have to be good)
| injects some life into the organisation.
|
| If your in-house team is toxic you need to go and be the one to
| monitor that.
|
| I worked on a team where when the CPO was there it was actually
| amazing but the moment he left their idiot head of engineering
| and middle management had a field day doing nothing
| nurettin wrote:
| I worked for a customs-logistics company and did some
| integrations with european cargo firms. EDI is definitely
| something a senior developer can figure out and parse/generate.
| Wiring your system through api/sftp servers won't be that hard.
|
| The main problem will be the UI. Use existing frameworks!
| Telerik, devex, anything you can get your hands on. Don't let
| your project become hindered by someone's half-ass attempt at
| reinventing a data source and pivot grid. It already exists and
| it is a solved problem.
| rufugee wrote:
| I'm a CIO/CTO in a similarly-sized (revenue, although we have
| roughly 900 employees) company in the distribution space. We do
| almost all development internally, but I have been developing for
| decades so I know what good looks like. I've had good luck
| attracting a jolly band of developers and devops.
|
| I despise outsourcing development to third parties unless I
| absolutely have to. The quality of work is just better with the
| internal devs, and we retain the knowledge of our entire stack.
|
| Our software is the life blood of our business, so that's a big
| win for us and it sets us apart from our competitors. I'm able to
| outpace them from an innovation perspective.
|
| All that said, unless you're very technical or you have a strong
| IT executive on your team, this approach won't work.
| puuush wrote:
| I read: "I'm an executive at a mid-sized logistics company (~200
| employees, $200-300M annual revenue)"
|
| I think about: https://www.bloomberg.com/graphics/2015-paul-ford-
| what-is-co...
| AlexMuir wrote:
| Feel free to drop me an email - alex.muir@boxmove.com
|
| I wrote the logistics platform for our company - UK-based, PS4m
| revenue. I'll be happy to have an honest chat with you if it
| would be helpful.
| superice wrote:
| I'd recommend against it, but then again, I'm building software
| products in this exact space with my launching customer being a
| 200-300M annual revenue logistics company. I don't think they
| could do it in-house. You don't give a lot of info on the exact
| niche you are in, but the username tells me that you're doing
| containers in European context, most likely shortsea or domestic,
| not deepsea. Me telling you the ISO6436 type code for your
| username is either LEG1 or LEGB depending on max stacking height
| should tell you I know my stuff :)
|
| Your biggest pain point is most likely that you know your
| business very well, but you probably do not know enough about the
| business context of your partners. If you are running a small-ish
| container terminal for example, you really should know how the
| depot department of the major carriers are managing their empty
| stock so you can decide your stacking strategies in the yard. You
| should probably also have an understanding of benefits vs
| drawbacks of tower cranes vs gantry cranes found at bigger quays.
| That then influences what your TOS should be capable of. Same
| thing goes for intermodal transport planning, you really should
| know not only how detention/demurrage works, but also what tricks
| you can pull to optimize for it, and how shipping lines monitor
| this internally. If you are building stuff in-house, you're
| inevitably going to be limited in your understanding of the wider
| market. Short term that's a huge improvement (more tailored
| software, better flexibility), long term that might cause huge
| issues.
|
| I can certainly understand the frustration with third-party
| products. Your description of 'they are understaffed and the
| platform is stagnant' could realistically apply to pretty much
| any software provider in this space. There is a huge opportunity
| for somebody to swoop in and build something, the bar for this
| sector is mostly something that doesn't straight up suck. And I'm
| going to be honest: we're trying to be that somebody.
|
| If you'd like to talk, my contact details are in my profile. I'm
| happy to show you what we're building, and tell you what that is
| like behind the scenes. If you go ahead with your plan to in-
| house it, let's stay in contact, perhaps we can learn from
| eachother.
| x0x0 wrote:
| It's also worth mentioning that the economics of software may
| be very painful. Right now, the cost of building all that
| software is being shared across all the customers of this
| company. OP is proposing his/her company bears the entirety of
| it.
|
| Assume you can hire good sr engineers. This project badly needs
| some scoping to figure out how much eng time and how much risk
| it will take to replace what exists.
|
| I've worked on software for small-run scientific instruments:
| think 200 to 400 sold. The cost of software can be 30% of the
| total cost of the projects. It may well be that, given what
| customers are willing to pay, there isn't enough money in this
| to build good software.
|
| And for OP, for core software, if customers interact with it as
| well, you likely need follow-the-sun ops too.
| andrewstuart wrote:
| Whatever you do, don't hire some tech bro who tells you that you
| should build this in Ruby On Rails or Elixir or Elm or Rust or
| something on the cutting edge in any way.
|
| This is standard corporate technology and needs standard ordinary
| technology. There is zero requirement for this sort of
| application to use anything fancy. Indeed if you use fancy
| technology that scratches the itch of a tech bro then you are
| buying yourself problems hiring and recruiting developers - this
| is one of the worst problems you can have. Not such an issue
| right now while the employment market is down, but a _massive_
| issue when it is not.
|
| Use ordinary technologies, any of these things are fine:
|
| Java
|
| C# .NET
|
| Python
|
| TypeScript
|
| Postgres
|
| Also, don't use cloud specific technologies such as serverless.
| Just write software that can run on an ordinary Linux server.
| Once you start using serverless you are bound to that code and
| that cloud forever. Also, and other may argue against this, but
| my experience of building application using cloud technologies is
| that way too much developer time and effort goes into making the
| cloud work and not enough into writing application code. Have a
| general directive in place to use the cloud for running compute
| instances and avoid using cloud application services unless
| really necessary and have a process where doing so requires
| signoff from the top. Nothing wrong with cloud virtual machines
| and email sending but just run most other things on Linux - own
| your own computing infrastructure and be in a position to pick it
| up and move it elsewhere or even on premises if you choose.
|
| In summary, beware tech bros advocating anything except
| Java/C#/Python/TypeScript/nodejs/Postgres, don't use serverless
| and use cloud computing for virtual machines, email and DNS and
| not much else.
|
| Hire a development manager with experience building corporate
| applications and let them hire three developers, a tester and a
| business requirements analyst and that's phase one of your "bring
| it in house project". Build a series of small chunks of
| functionality, don't bite of more than you can chew.
| kyrofa wrote:
| There are companies out there (full disclosure, I work for
| one[1]) that create and maintain custom software for companies
| such as yours, including websites. They work with you to make
| sure you have exactly what you need. That direction may prove
| more effective than trying to bring tech talent onboard.
|
| [1]: https://www.miriamtech.com/
| ipmb wrote:
| I'd be happy to share my experience with you. We've solved
| problems like this for a lot of folks with small or non-existent
| internal tech teams. I agree with the small team of experts
| approach, but there are pitfalls there too.
|
| Feel free to reach out pete AT lincolnloop.com
| PaulRobinson wrote:
| One thing to be aware of is your existing supplier might play
| hardball with your data.
|
| I've known companies in this situation try everything from price
| gouging ("it'll cost you $10 a record to export your 2 million
| records"), to just flat out refusing to pick up the phone, answer
| emails, or reply to legal threats: in principle a court can tell
| them they need to hand data over, in practice they can drag their
| feet.
|
| As a former CTO I think you might need help to help you figure
| out your strategy in more detail and then get it delivered.
| Plenty of non-tech businesses have dev teams, and it's becoming
| more and more frequent in my experience. You can attract a team
| with flexibility, autonomy, a promise they can learn new things
| and a great mission. A good CTO with experience in startups can
| probably help you get that lined up right.
| rachofsunshine wrote:
| Do you have a clear sense of what, _exactly_ , it is that you're
| trying to accomplish?
|
| You say that your third-party product "functions, but barely". In
| what ways is it failing you? What do you want it to do that it
| doesn't? Can you articulate that? What features do you want them
| to implement that they aren't? And more importantly, what are
| they doing that you couldn't do without them?
|
| Before my current role, I was a PM (for a company of roughly
| comparable size to yours). And that job exists because "just make
| it do X" is in fact a project that requires days if not weeks of
| very deep thought, because X always involves dozens of
| assumptions and edge cases and complexities that are not obvious
| even with domain expertise.
|
| -----
|
| To answer one of your specific questions from my perspective as
| the CEO of a tech recruiting company:
|
| > Besides, can we even attract experienced developers to a non-
| glamorous industry like logistics?
|
| Sure. Building an exciting product is something that motivates
| some developers, but it's not the only or even the primary thing
| that does. Common motivators in our candidate pool, in rough
| order of most to least frequent, are:
|
| - Being able to work remotely (this, all by itself, will 10x your
| candidate pool overnight even if you're not working abroad)
|
| - Salary
|
| - Work-life balance
|
| - Stability / trajectory
|
| - Autonomy / lack of non-technical meddling in technical work
|
| - Working with specific technologies
|
| Remote work + reasonable dev salaries is already enough to have a
| decent pool of candidates. And I suspect that the nature of this
| post means you're much more open to treating a dev team as a
| value add and not a cost center, which is already better than a
| lot of people do.
|
| I'd be happy to talk more specifically, if you want, about how
| you might pitch yourself to engineers (my email's in my HN
| profile - and no this isn't a sales honeypot, I'll tell you what
| we do if and only if you give a damn).
| nsiemsen wrote:
| I agree with a lot of the "how to" suggestions here. One addition
| is that you need to have a small number of key non-development
| employees really guide the development with strong opinions on
| functionality. This will likely mean your strongest folks in the
| departments that the software will serve. I would avoid building
| this by committee. 1-2 of your best folks who will be the
| ultimate end users should have massive decision-making power in
| what gets developed, in what order, and for what purpose.
|
| Also, don't underestimate maintenance in your cost assumptions.
| Even after you've developed the product, you will need several
| people full-time just to maintain, update, and bug fix, let alone
| add new features that got sidelined during the initial
| development in order to meet the MVP.
| coffeemug wrote:
| Drop me an email at coffeemug@gmail.com. Lots of ideas I can't
| share here.
| mgl wrote:
| It's actually great to read your story (apologies!)
|
| The answer is YES and we have built Openkoda* as an open-source
| alternative to Salesforce Platform and other closed low code
| vendors specifically for these reason.
|
| Happy to connect and share our story.
|
| * openkoda.com
| jbs789 wrote:
| I observe that the question is focused on "should", not "how". So
| my first question is less about the "how" and I am more curious
| about whether differentiated tech builds your competitive
| advantage?
|
| Suspect you can further differentiate with a bespoke team, then
| defer to others on how to execute.
| casesandberg wrote:
| If you choose to stick with your existing provider, you can
| negotiate a service contract where the provider hires and manages
| engineers that work exclusively on your account. We did this in
| the past with pretty good success. We were planning to exit in
| 1-2 years and didn't want to invest in an entirely new platform
| or build it ourselves when we knew the acquiring company would
| end up rolling up our service into their existing
| platform/infrastructure.
| snow_mac wrote:
| "attract experienced developers to a non-glamorous industry like
| logistics" -- Pay them well and offer a remote work environment.
| If you're interested in chatting with a senior / lead developer
| who's owned a lot of projects from the ground up I would love to
| chat adam.bourg@gmail.com - 720 491 0562
| chasd00 wrote:
| One thing to consider with in-house dev is there's no one to yell
| at except the man in the mirror. Think about this, you need an
| application as part of your workflow, you're not in the business
| of selling the software development. What you risk happening is
| employing a dev team who's job becomes writing code 9-5. Your
| developers don't have much of an incentive to deliver a v1, they
| get paid no matter what.
|
| A small, experienced, eat-what-they-kill consultancy may be
| better. If they don't deliver they don't eat. A firm like that is
| motivated to get things done on budget and on time. You'll get
| the application you need to move on with your business rather
| than having an internal software development firm 100% funded in
| perpetuity by your real business.
| jbjbjbjb wrote:
| I think it's certainly doable and sustainable.
|
| Pitfalls you're not considering:
|
| Maintaining it. It will have an ongoing cost of keep things
| running, secure, up to date. This will get bigger and bigger as
| the project becomes more integral.
|
| The right mindset. You don't want devs who approach this as is
| they're building the next Amazon or Google. You don't want it
| over engineered and have devs trying to be too clever/ padding
| out their own CVs. This might also make it pretty boring.
|
| Unless you have some dev who is very interested or experienced in
| logistics you'll need a some people from the business investing
| time helping explain what the feature is and acceptance testing
| it.
| carom wrote:
| What industry, what software, and what is your budget? If it is
| profitable to build and more than one customer, I am sure
| numerous people here would jump on the idea.
| jasonteunissen wrote:
| Hi, my ex colleague pointed me here.
|
| This is exactly what we specialize in: logistics and transport
| digitization. we are www.lowcode.co.nz and have experience and
| connections in EU, but NZ needs some help with digital maturity
| (and much nicer weather here too).
|
| We are currently building our SAAS platform for cranes and hiabs
| called mothertrucking.co.nz (sign up for free as we are in
| stealth beta)
|
| What you have mentioned is exactly the pain we see a lot in this
| industry, (tools get made, then the budget stops, and it becomes
| hard to maintain, and all the original devs have moved on to more
| fun projects.)
|
| Id be keen to have a talk to understand your struggles.
| Jefff8 wrote:
| Firstly, it's important to note that on Hacker News, responders
| are probably going to be biased towards writing software that
| solves your problems.
|
| Secondly, it sounds to me as if you are jumping ahead, and
| favoring one particular solution, rather than looking at this as
| business problem. If I were tackling it, I'd be making a list of
| all the possible solutions: - Stay as you are - Stay as you are
| but make a deal to buy the source code/or perhaps the company
| that makes the product if that's feasible/or the division - Buy-
| in an entirely different commercial platform - Build your own as
| a clone of what you already use, and extend out - Build your own
| as an entirely new system - something that exactly right for you
| - Glue systems together to get something that works for you -
| Probably there are more.
|
| Then I'd list the advantages and disadvantages, the risks, and
| guesstimates on costs and monetary benefits. This does not need
| to be a long process - a month and a spreadsheet.
|
| At the end of this process, I'd be thinking about next steps to
| facilitate the likely candidates. E.g. initial talks to vendors
| or approaches through an agent about buying the company.
|
| If build-your-own is still on the list, then I'd look at having
| someone spend a few months documenting and thinking about your
| existing software, specifically with the aim of mapping out the
| likely pain-points - e.g. does the system use an interesting
| scheduling algorithm and if so, what is special, and where does
| it fail?
|
| This stuff will eventually form the basis of spec for the
| backbone of a new system. But it's first job is to build some
| organizational expertise in the software, rather than the use of
| the software. You want some maps of the territory.
|
| If at the end of this, you have a sense of the pitfalls, then I
| would think about mapping out what is really needed -
| interviewing all the levels of your org that have an interest -
| from the end-users/operators, through to the board. You want to
| find the stuff that's not documented. You probably don't want to
| get to a spec, but you do want to have a document that accurately
| reflects your needs (and also the love-to-haves, and the
| opportunities to extend)- and it can be used to judge whether a
| buy-in or a build-your-own can successfully meet your needs.
|
| If you even get this far, this is the point at which you should
| be deciding between build-your-own and buy-in.
|
| And if it's build-your-own, then this is where you take all the
| stuff you've learned to spec it.
|
| And if this is the solution, I'd be thinking about what
| technology will serve you best at least cost, now and ongoing.
| E.g. should you be building a web app, and if so, what tech could
| function as the core, so that you don't have to spend money on
| re-inventing layouts.
|
| Strategies - these are not secret: - Make your business a place
| that people want to work - that means getting rid of bullies and
| trouble-makers, and encouraging a supportive environment - Make
| sure there are challenges, and they are achievable - Offer
| excellent packages - this can be a mix - work-from-home,
| healthcare, pay, etc - it's the whole package that matters -
| Understand that if you don't offer people a pathway to
| improvement, then you will lose them - Ensure that the actual
| physical work environment is conducive to concentration - Ensure
| that the software team are a proper part of the fabric of your
| company, and not an afterthought.
|
| Transitioning software too, is not rocket-science. You need a
| solid plan for the transition. You need to train people
| constantly. You need changes to be small, incremental wherever
| possible, and clearly communicated ahead of time; you want the
| people who use the software to feel in control - that this is to
| help them, rather than to hinder them. And if there are
| organizational changes as a result, then you need to be sure that
| you are not shafting staff; you want people on your side, not
| against you.
| y1426i wrote:
| Building a single tenant system is 10x simpler than building a
| multi-tenant SaaS. App development is so much faster these days
| and you can build a significant system with just couple of remote
| devs. Even easier when there is an app from which they can copy
| from.
| chrysoprace wrote:
| When you say provider, I assume you don't own the IP and that
| you'd be starting from scratch. At my work we owned the IP from
| software developed by a third-party which we then brought in-
| house and hired on software developers (myself included). The
| biggest challenge has been the loss of tribal knowledge of the
| codebase and the use cases that brought the system to its current
| state over a decade.
|
| The boring answer is that you'd likely need to put together a
| business case. What's the benefit you'd get from developing it
| in-house? Is it worth the projected cost & time-frame (which is
| likely going to be inaccurate since estimating software is
| inherently difficult) to fix the painpoints? Would you look to
| offer the new solution to other potential customers (which may
| even be competitors to your main business)?
|
| As for attracting talent, I've worked in the tech sector of
| pharmacy (Australia) for nearly a decade and while the tech
| sector there is small, the hiring pool is just like any other
| industry since we don't hire for pharmacy experience.
| johan_larson wrote:
| Do you have any people in your company who could build what you
| need if given the time? Sometimes there are people who are pretty
| handy with coding who aren't called "programmers". They may be
| analysts or engineers or something like that. And is there anyone
| who understands the domain, has solid leadership skills, and at
| least a bit of tech skill, enabling them to serve as a project
| lead?
|
| If you have both of these, you could conceivably use your
| existing staff to build at least a limited-functionality version
| 1, and backfill the jobs they used to do with new people. If not,
| you have the harder problem of needing to hire people to do
| something you don't know how to do at all.
| janalsncm wrote:
| Without having a ton to add, logistics might not be the sexiest
| industry but you can do a lot to make the role more sexy,
| especially to senior engineers. Making the role remote is worth
| $50k or more in and of itself, and vastly broadens your talent
| pool. Juniors are the ones more likely to be willing and able to
| relocate and commute.
| iamgopal wrote:
| We do contract base software development in India, and have
| worked with https://haulog.com/ recently. If you're considering
| to start with outsourcing to jump start, Let's exchange few mail
| ( patelgopal@gmail.com ) and see if we are compatible enough to
| try and make a demo or something.
| bhaney wrote:
| No. You will almost certainly fuck it up because you're not a
| software company and very likely don't have a culture conducive
| to efficiently creating software or identifying and retaining
| software-related talent. Your costs will balloon and your output
| will pretty quickly slow to at least as much of a crawl as the
| vendors you're using, once attrition and tech-debt catch up with
| you.
|
| If anything, you should contract with a software company that
| builds custom software solutions for niche businesses. But be
| very careful when identifying the company to go with, as a lot of
| them are essentially scams.
| capitanazo77 wrote:
| Senior programmer here. Yeah. You're in a spot where you need a
| senior programmer and a couple of juniors but can't guarantee
| steady work for them long term.
|
| Also, in house software needs to retain knowledge, otherwise the
| knowledge disappears when the senior resigns.
|
| I've 20+ years experience with business like yours. Contact me.
|
| https://x.com/eduardoarandah
| nicolasrod78 wrote:
| I can see there's a lot of good advice in the comments. I just
| wanted to contibute my 2 cents to the matter. I've done a lot of
| conversions, interconnection of disparate systems, migrations,
| monkeypatching and straight abominations in my day. In your
| position I would hire senior freelancers to patch the system in
| interations. First, fixing the most anoying issues you have in
| order to streamline the whole process. This will allow the
| programmers to really understand the domain and based on that
| knowledge iterate and consolidate pieces of the architecture
| until you have what you're looking for. I don't really believe in
| complete rewrites or starting from scratch based on my
| experience. Most of the users/companies I've dealt with (small
| and big) don't really have documented processes and domain
| knowledge. Well, that's not fair. It's rare those are documented
| and up-to-date. That's better :-) I agree with some of the
| comments, the technical challenge is what attracts people (at
| least that's my case). If you're looking for people to tackle
| something like this, please send me an email :-) Cheers.
| d_burfoot wrote:
| Hi, I built a low-code platform WebWidgets.io (WWIO) specifically
| for companies that are too unique for cookie-cutter SaaS products
| to work well, but not big enough to do their own development
| work. I've built several WWIO apps for small
| businesses/nonprofits that have saved multiple FTEs worth of
| manual data work in Excel.
|
| WWIO achieves high productivity by moving all the logic into
| front-end JS code, which accesses and persists data to SQLite DBs
| on the backend with a simple, standard API (for VIP clients like
| you, I would augment this with some backend Python scripts). This
| approach makes it super-easy to build the CRUD features, while
| allowing a backdoor when you need special functionality. For a
| sports camp nonprofit, we did a backend integration with Google's
| OR Tool library, to solve their scheduling problem with a single
| click:
|
| https://webwidgets.io/blog/sportscamp.html
|
| I would love to do a call to discuss your needs. If WWIO seems
| like a good match, I'd be happy to build an MVP at no charge and
| create a strategy to move forward with minimal risk. If not, I'd
| be happy to share my thoughts as a seasoned engineer. Contact
| info in profile.
| kylehotchkiss wrote:
| Can you purchase the provider and then own the existing code, and
| hire up to build on top of it? Tear It All Down might be an
| expensive fallacy.
| codr7 wrote:
| Pulling something like this off is pretty serious business, there
| are a million things that can and often do go wrong, which is why
| so few software projects are successful.
|
| And you're in a pretty shitty position, to be honest. Because you
| don't even have the skills required to hire the right people.
| Much less handle the project yourself and delegate tasks.
|
| My advice would be to find someone you trust with plenty of
| software experience, explain the situation and LISTEN to what
| they have to say, especially when it's not what you want to hear.
|
| Or you're likely going to waste a lot of time and effort making
| the situation even worse, happens every day.
| vlovich123 wrote:
| Don't see contact info in your profile. Feel free to email me at
| gmail - lots of experience leading tech teams, but none in the
| logistics space. Currently mid transition and exploring
| opportunities. Might be interested depending on opportunity and
| details.
| Aerbil313 wrote:
| As a freelancer myself, I am delighted by the amount of
| freelancers in the comments. We're very often heavily
| underrepresented in the wider software world. Guess it has to be
| that we are still the minority, lol
| ownagefool wrote:
| Many of us, myself included, will be predisposed to controlling
| our own SDLC, largely because of bad experiences with vendors.
| Personally I've had vendors shutting down a product that was core
| to our offering with basically no notice, performing poorly but
| not accepting responsbility, just milking T&M, and just straight
| up lying.
|
| The problem is, all those outcomes exist with hiring your own
| developers, and it's really difficult to mitigate unless you
| yourself are a strong developer who can run projects and teams
| and look beyond what people are telling you.
|
| Reality is, it's impossible to answer the question without really
| getting more information. Specifically around what you spend on
| outsourcing / licensing, what the feature set you're going, what
| the budget for the new team would be, and what the expected
| outcomes and timelines are.
|
| Without the context though, some quick fire opinions.
|
| - You probably at least want the dry powder. i.e. the person
| making the outsourcing decisions should at least have the
| technical accume to bring it in-house if required. If they're not
| a person that could, then outsource is the only decision they can
| realstically make, then they'll tell you it's the right decision
| even when it isn't.
|
| - You need someone mature. If they just want to build everything
| from scratch always because of some personal bias, you'll end up
| amassing tech debt in areas where there were limited risk /
| benefit. Developers will 100% tell you you need to building
| things because it's interesting to them, even when you don't
| really need it.
|
| - If you're going to do this with any near-term success your
| first hires are really key, and they likely won't be cheap. I see
| people debating brining in a team vs a CTO, but both strategies
| fail if the quality isn't there. Figure out how to validate
| quality.
|
| I was CTO of from ~25m to ~PS75m ARR UK Point-of-Sale org with
| ~100 tech employees. Those roles are hard to find. This sounds
| like a great opportunity. Lots of folks will likely do the hard
| sell. Good luck.
| acrooks wrote:
| Hi, I have a lot of experience in this space - software for
| logistics, supply chain, shipping.
|
| I have helped companies procure off-the-shelf software, helped
| them build in-house technology, and have a lot of connections
| with companies like yours in both sides of the table (from
| largely in-house all the way to the other side to largely
| subscriptions), so I've seen broad examples of what works and
| what doesn't, and how businesses can leverage technology to get a
| competitive edge.
|
| If you want to chat and learn more, I'm happy to make some time -
| email address is in my profile.
| FpUser wrote:
| I can speak from the other end. If you do not have software
| development culture (and you do not) there is a great chance you
| will not succeed. What will most likely work is hiring small
| company that specializes in developing software products for
| niche industries.
|
| I happen to be such company (been doing it for 25 years already).
| If interested reply to this message with your contact details. My
| company is based in Canada but we are we work mostly remotely and
| have developed some products for European Countries. If
| interested send contact details to this temporary email:
| pegoya2186@alientex.com
___________________________________________________________________
(page generated 2024-08-08 23:00 UTC)