I did exactly that with a custom GPT and it works pretty well. I did my best to push it to respond with its training knowledge about brand reputation and avoid searches. When it has to resort to searches I pushed it to use trusted product information sources and avoid spammy or ad-ridden sites.
It allowed me to spot the best brands and sometimes even products in verticals I knew nothing about beforehand. It’s not perfect but already very efficient.
That was indeed a big parameter. We missed someone on the team able to connect to us to one or two large early adopters. We learned that building a good product and building a company selling it are two very different things !
Lack of traction basically. We ran out of time and money. Also we, maybe wrongly, did not feel like we could compete with the big ones without clustering. Yet we had a lot of fun building it. It was a thrill to see our product deliver performance on par or above in-memory messaging systems while being fully persisted and fsync’ed. I’m sure you know what I mean ! Good luck with Iggy anyway. Looks like you are on the right track !
They make money because growth. Any strategy that is not based on information asymmetry or unique clever use of information makes less than the market on average.
You couldn’t feel that way if you had no doubt or did not care about your level or worth as a developer. So you do care about how others perceive your level and you are not totally convinced that your self evaluation is right.
I would say don’t judge yourself too much. You don’t have to be perfect (especially if you are not, and nobody is). You probably are in this business to learn, so give yourself some room to learn a bit (or a lot!) more. People that criticize your work may be wrong. Don’t take their criticisms as absolute truth. In case you feel they may be right, drop your ideas right away, ruthlessly steal theirs and make them yours. This is how you don’t get stuck in local minima. You don’t have to care about having been wrong, there are more constructive things to do.
It’s time we fork a « software design » category from the software engineering catchall.
Yet many great suggestions on this topic but one is missing, which in my opinion sums up a lot of the software design classics : « The Design of Everyday Things » by Don Norman.
You can deploy your whole monolith on one single lambda and it will scale the same. It may even help to keep it hot.
Services, micro or not are only really useful when load factors are vastly different and you’re not serverless. Or when you have sufficiently many large teams and a sufficiently large codebase that a single deploy becomes unmanageable because too much communication / coordination is needed.
Right. Then HTTP requests being share-nothing they horizontally scale in a single instance, too. Just spin more cores.
This microservices craze has been mind-boggling. As for many other fashions, it’s excruciatingly difficult to make young or even average senior devs understand it’s bullshit at 90%.
When Netflix does it and the self-appointed expert bloggers praise it, as a CTO or team lead you’re pretty much screwed.
I call it wasting time trying to fit square pegs in round holes. Many things and approaches have their virtues and their place, be it top-down, bottom-up or tests. Silver bullet techniques and dogma have absolutely none.
« Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. » [1]
Here is an event stream abstraction that has very strong semantics (exactly once in most cases) with simple usage examples, native HTTP and websockets APIs, strong atomicity and durability guarantees [1].
What it doesn’t have is clustering and a father that’s != null at marketing =]