10+yrs fCTO/fCPO experience in data-heavy at scale applications. I take on 3-4 projects a year helping companies/teams at their inflection points.

Location: UK

Remote: Yes

Willing to relocate: No

Technologies: full stack, especially data-rich / data-heavy applications. E.g. large scale or high complexity of data. Backends include python, node (also java, PHP and others); frontend mostly React but enough experience to adapt. Very deep knowledge of infra and experience in infra-as-code, scaling etc.

Most of my roles are fCTO/fCPO at inflection points: idea to MVP; MVP to stability; stability to scale-up.

CV: See https://danfrost.co.uk/

email: dan@danfrost.co.uk

I've found: - amazing business running on ball of mud code maintained in an insane way - the perfect architecture, CI/CD, TDD where the business/product has little/no value for the customer

Also, I've seen the same stacks succeed and fail. The only common thing I can see is:

- when the tech team fully understand the stack they're using - when the tech team fully understand the product and business they're building (and can make appropriate trade offs)

There are a bunch of basic tech things. E.g. the underlying infrastructure has to be performance, scale, secure etc. There's also the issue of choosing a tech you can actually recruit for.

I have seen the same, but came away with a different conclusion.

Shoddy architecture and even a bad product can be compensated by marketing, hype or a good sales team, while the most pristine architecture and codebase will not help you at all without any customers.

We technologists often focus on the technical aspects, but in many domains they are the least important part for a startup.

You are in the business of doing a thing, not having an aesthetically pleasing tech architecture.

It is true that having a nice tech stack can make doing your thing easier, but it can also distract you from doing your thing well.

Very good summary. I was going to write a similar thing.

Tech stack is important but (customer) money in the bank is importanter.

Your daily reminder that FB started with PHP. Ship and sell first, the rest can be done later (yes your customer doesn't care that you rewrote your backend to use nanoservices in Go deployed to hundreds of lambda functions).

Facebook was originally a garbage PHP app.

Technically, it still is.

From what I’ve seen it all comes down to org culture. Have a ball of mud that’s a nightmare, but senior engineers who are kind, empathetic, and enjoy mentoring, no problem. Have a perfect architecture written perfectly in $lang by elite devs that don’t have time for mentoring or collaboration, guaranteed failure.

Thanks - good point. I need to change the phrasing.

It's a facebook messenger bot at the moment but it'll be native app eventually when the details of the chat content are ironed out. I hope to continue the FB bot being free forever, but it depends how it pans out..

No - this is me: https://twitter.com/danfrost

Do you know what the roadmap is for this? It looks like they want to build a terminal, but I can't see how it's significantly different from what we've got at the moment.

Answering my own question somewhat: https://www.scotthyoung.com/blog/2013/07/09/side-project/

I nearly worked on an idea like this 4 years ago. End-to-end podcasting which helps people make good quality, listenable podcasts. +1 from me

Social Researching: Like social bookmarking, combined with joining comments so you can share and collaborate on your research.

Think "trails" from V Bush's "As we may think" article, implemented so we can collaborate. As users start bookmarking things in their own trail, the app works out what other trails are similar and suggests you merge your researching efforts.

This idea has a /lot/ of use cases. I'm not sure how easy it would be to make a business out of it -- maybe you allow public collaborations free, and charge to take it private.

It'd sink or swim on the details of the UI, though, and I have frankly no idea how to get those right. Lots of painstaking user testing, presumably.

Google wave was great for almost this, actually, minus the matching / merging part! Sad to see it go.

Yes. I think this idea is almost in many things but you need to give the user the structure to both read and contribute to a thread of research.

Every Sunday