I think there's a big risk there of hiring a "CTO" who hasn't coded in 10 years and it's just a paper pusher. Ask to see the GitHub.

This will filter out 90% of candidates, but yes. Problem though is you need another turtle layer to evaluate the git commits. They might have been just changing CSS.

>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.

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.

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.

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.

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.

Or just the principal person behind the product. Careful approach and they may jump ship.

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.

Hi, are you looking for support to build a team out? Thank you.