How to move forward from what's essentially a prototype, which was never intended to be sold to high-profile clients

Question

Ok so I started off with this prototype piece of software in my attic and now it's has become a company. I really can't be too specific, but imagine a server side scripting thing that is now being sold abroad to high-profile customers. There are people to whom this might sound great, but in fact, some years down the line this is really wearing me down.

It started as a one man company, and as luck would have it I quickly found a launching customer who brought me two more, and then after some year of struggle I settled with a commercial guy who called himself an IT entrepreneur and said he knew how to build up a company. Indeed we got like 10 more clients, hired a guy or two and have been implementing ever since. I'll talk about the actual business model another time, but the problem I'm facing now is this:

• I built it in this prototype language just to make my point about the market opportunity. I'm not a software engineer and have probably violated all the rules in the book. But it works.
• I built my own release mechanism and it works.
• I use this weird mix of technologies to make it all work together. It works.
• Never really documented anything really. It's all intuitive.

But you might have already guessed: I'm the only one who can make it work. So far this went fine, but it's not scalable because I'm not scalable. The more implementations we have to maintain, the more workload I get. Risks for customers are high. No gravy train. Runaway train and I'm the only one who knows its running away.

So what I now have to do is to come up with a plan to set up a development team whilst dismantling a bomb on a runaway train, and the other guy does not really see the need, or closer to the thruth probably, does not want to see it. So if somebody must make a decision, it's probably me. I always liked the thrill, but I'm getting tired.

For now, I see some options:

• We're already looking at Java engineers, but whoever want's to jump on a runaway train must be a cowboy just like me.
• Do an executive search for some guy who we can make a director of development
• Find a investor who helps out with money and whose development team we can use to refactor the whole thing
• Continue in dutyful quiet desparation until derailment.
• Jump off the train, and after recovery from the law suit see what's left in the wreckage.
• Go to the back of the train and hope I'll survive the crash.

I think the best step forward is the first option. I'm deliberately being candid about the level of desparation here - and I'm deliberate in placing the question on Workplace because what I'm looking for is advice from people who come from the workplace and know how to best set up development teams in awkward situations.

Answer 1

You just described literally any tech company ever. Yes, you keep the high speed train running while you replace the engine written in ${language you don't like} with ()=>"language you do like".

That is the SHORT answer to your question.

The other option was "close this as too broad" because, "How do I get off the prototype, scary tech stack onto a good one in a small company?" is the subject of a multitude of books, talks, the focus of meetups, and why people who are very good at it make a lot of money (between 6 and 10 figures). Here are my thoughts on your ideas:

We're already looking at Java engineers, but whoever want's to jump on a runaway train must be a cowboy just like me.

Or, possibly, you are paying well with very good equity, so they know the risk they are taking and are not being reckless. Maybe you can pull someone at a Fortune 500 company who is "looking for a change."

Find a investor who helps out with money and whose development team we can use to refactor the whole thing.

Your VC provides management expertise as much as money. Sounds like you could use that.

Do an executive search for some[one] who we can make a director of development.

They will require: good pay, good equity, and a chance of success.

Jump off the train, and after recovery from the law suit see what's left in the wreckage.

If you have legal issues please contact an attorney ASAP. If you're going to have legal issues, seriously they won't be easier to solve after letting every worst-case scenario take place.

Answer 2

Redevelop. Nothing new about what you're doing. I'm not a developer, I had an idea, made a product that worked, found some clients and sold it to them.

Then I invested some of the money into redeveloping the whole product and improved it at the same time. And I still invest money upgrading it. It's really as simple as that.

The problem you have is your business is investing in sales, not tech. You need a balance. No need to use cowboys, spend money to make money. The people I use are very expensive, but I have peace of mind.

I found sales at the start to have gone in phases. Sell, consolidate, improve, up the price, then another sales drive.

As far as setting up a team goes, this is the easiest part. Get qualified experienced people on board. Make it a priority, sit down with them and just go through everything step by step. In my own case one experienced full stack guy took my ideas and a heck of a lot of work and redeveloped in to a working scalable product in a few weeks, we tweaked for perhaps 6 months on and off. But in practical terms it was just a few weeks for him to do the grunt work and build it. And because I worked through the whole thing with him, I learnt a lot and know and understand every piece of the code, and wrote the documentation myself afterwards.

Redevelopment is a heck of a lot easier than development, because you already know in detail what you want to achieve. You don't have to make anything up. It's just a matter of solving translation problems.

Answer 3

The first thing you should do is take a stab at documenting the process. You do not need low level details just explain what each part is how it fits into the process. Your train is not runaway, you just do not know what the track that you are on is or where the other tracks go. Think of the documenting process as mapping out where the tracks go. From there you are no longer lost and can work with a team to figure out what set of tracks you want to be on and how to get there.

Bring in someone with experience in doing something similar to what your product does. You do not want another cowboy coder for this position. You want someone who can set your company toward a sustainable future and all another cowboy is going to do is keep throwing the switches at random. Bring in a professional, and work with them to develop a strategy moving forward. This should be someone you can see building a team of developers to implement that strategy.

Once you have the stable product you are comfortable with then you can focus on growing your business, and let the developers worry about new development and keeping the thing running.