DEV Community: Lev Perlman 🏳️‍🌈

Are wrapper-apps around the ChatGPT API — a viable business? (hint — not really)

Lev Perlman 🏳️‍🌈 — Mon, 08 May 2023 15:16:54 +0000

ChatGPT and AI have been buzzwords for quite some time, but their impact is now truly being felt by everybody, as their integration into different domains is becoming increasingly commonplace. Especially so, we are witnessing a wave of ‘wrapper apps’ — essentially materialising a sexy UX in front of the ChatGPT API, tailored for a specific industry or usecase, and that’s it.

Is it viable? Let’s think about it together; 👇

Point 1 — No value no gain;

TL;DR — a React Native app with ChatGPT is only viable if it has a solid business idea at its core.

Businesses & startups that offer wrappers around ChatGPT APIs or similar can be sustainable, but only if they have a true USP (like any other startup), and the AI wrapper ‘thing’ comes just as an additional benefit or optimisation. The main USP can be in tech, business, or marketing, and not just a nice Material Design or AntD mobile app, making queries to ChatGPT for tailored results. Businesses need to have experts in their respective industries who have a deep understanding of their customer’s pain points, workflows, and needs.

Point 2 — Fundable? Not so sure.

The second issue is whether these businesses are likely to get investment. Investors are eager to back startups that promise to deliver AI-based solutions for different sectors. The attractiveness of these investment opportunities has been supported by research, such as the report by PWC that estimates that AI will contribute $15.7 trillion to the global economy by 2030. The increasing number of funding rounds, such as Appen’s successful $319m funding round, indicates the level of interest investors have in AI-driven startups. Nonetheless, investors also place a premium on the ability to deliver tangible value, which can be proven through strong partnerships, revenue growth, and solid user adoption levels.

Looking back at the first point, imagine your investor asking you “OK, you’re going to get your $1m seed, but what’s the end-game?” — Make sure you have a solid answer here, and not just “we will keep using ChatGPT and add some new forms and screens”.

Point 3 — Ownership — nothing is yours anymore.

I could have elaborated on this more and more, but in this instance — I’ll allow ChatGPT to summarise it perfectly;

A complex issue
Think about what this means for you as a business. Think about scaling it up. Think about what you’ll tell your investors when they ask if you own anything you’ve created.

In conclusion, the growing number of AI-driven startups offering industry-specific applications is a welcome development that highlights the many opportunities for businesses to harness the potential of AI for their advantage. But don’t be blinded by it — it is not enough for a sustainable, fundable, scaleable business. To produce successful apps & platforms, businesses must tailor their services to specific verticals, work closely with domain experts, and deliver tangible value to their customers. If these startups can deliver these qualities, investors will undoubtedly be interested. But if their only benefit is that they have a beautiful UX with nice, thin fonts, wrapping a ChatGPT API and limiting its scope to just a single industry or usecase — that, in my opinion, won’t be enough.

It’s time backend developers got the ‘visual treatment’ too.

Lev Perlman 🏳️‍🌈 — Tue, 10 May 2022 17:59:23 +0000

Visualise backend tasks, in line with the 21st century

Open any frontend (FE) ticket, and you’re likely to find a whole variety of visual requirements, files, & documentation. Anything from the user journey flows, to mockups, designs, and fully-baked UI components — all are there to make sure you, as a frontend developer, get everything you need to get going & to do things correctly.

I am not criticising — quite the opposite. Frankly — I’m jealous 🤩

Most engineers would agree that the backend (BE) logic is not less crucial or complicated than frontend logic. If anything, some of the most business critical decisions and calculations take place on the backend.

Take financial calculations of a price 💸, for example. Or interest rates, fulfilment processes in an e-commerce product, or even live ML training based on production datasets 🧠. All of these aspects affect not only the profitability of the business, but also its risk tolerance, cyber security and legal compliance.

So how come the best a backend engineer can hope for, is just a dry textual ticket? Or, if they’re extremely lucky, a link to the relevant frontend journey? (Which would be over at this point, so would only act as documentation for the ‘entry point’ of the backend flow?)

I think it’s branding 🤷‍♂️

For some reason, backend development is seen by many as a realm of dark magic, a bear that should not be poked without reason. Or, putting jokes aside, it is seen as something that has nothing to do with the user journey and experience, even though it has everything to do with the user journey and the user’s experience.

But that doesn’t matter, we are here to change that, not to complain about the past. Here is what we can do to bring the backend realm into the 21st century 🤘

Plan end-to-end journeys, including the BE logic and permutations. Let’s look at a fintech example — here is how a simple KYC (know-your-customer) process would look like in an end-to-end journey;

🤝An example KYC flow, end-to-end

As you can see, it provides context to everyone. Frontend, backend, QA, Product Managers, everyone. Whoever looks at it — will understand what they need to do, and how their individual work connects to the individual work of other people in the team 🤝

Compile a story readiness checklist which includes the most important aspects, here’s an example:

Happy flow is clear and concise
Failure of every step is considered in terms of API response, and a corresponding message on the FE is defined
Timeouts and unresponsiveness of the server are all taken care of in terms of messaging for the user
Monitoring errors is as solid on the BE as it is on the FE, including the steps which lead to the issue, as well as the stacktraces and source mappings
Requirements for analytics events are outlined & well-documented, preferably in the same place as the user journey
Test strategy is defined, with edge cases clearly identified both for FE and BE
Release time is scheduled
Rollback strategies are defined & documented
What has to be feature-flagged — is feature-flagged, both on the FE and the BE

Make sure you’ve got a way to ensure that the BE works as expected. While it is easy to achieve this on the frontend (i.e a certain page leads to a different page, or the right message is displayed to the user, etc.) — it’s not at all trivial to achieve that in the backend 🤔.

This is where tools like STATEWIZE (of which, disclaimer, I’m a co-founder) would come into play, and assist with ensuring that the plan matches the reality, both on the FE and on the BE.

Tracking BE flows in a visual way

And this way, finally, backend developers will get what they, nay we, truly need in order to do our job in the most efficient, correct & seamless way possible.

Getting started with serverless in under 5 minutes

Lev Perlman 🏳️‍🌈 — Wed, 31 Mar 2021 13:56:04 +0000

TL;DR — Serverless can be simple, as long as you have the right tools in your hands.
Most tools today are not the right tools, making serverless architecture too complicated and convoluted.
We believe there is a better way.
A practical section is at the bottom of this article.

The past and the future

Let’s start with a simple fact;

Serverless is the future of the tech world

You may assume that the inevitable future has landed on you unexpectedly, and start exploring the different tools that promise you the ultimate serverless vision — Low costs, no DevOps, usage-based pricing.

To your surprise, none of the serverless technologies on the market make your life simple. Quite the opposite;

You find yourself struggling to deploy a simple function, dealing with IaaS many limitations (in data size, run time, etc) and reading through hundreds of pages of docs and questions
“No DevOps” in reality meant even more DevOps than before; Managing a repository with various serverless functions and deploying each at the right time to the right place becomes a complex task for DevOps magicians
Changing your mindset towards a serverless-based thinking feels extremely uncomfortable and makes you question your choices, your career, and your life in general.
Even after building several serverless functions, you discover that making them communicate with each other is a separate soap opera. How on earth are you going to orchestrate that?
Debugging. Oh my god. Some say that debugging serverless projects is more painful than it was used as a torture measure by the Mossad. We cannot confirm or deny such claims.

Why is serverless bad today?

To answer that question, let’s look at a picture of how your serverless stack may look like today:

Looking at that picture, what do you see?
All of these are functions. Can you say which one calls which? Which does what? And why? Who created it, and when?
NO.

How about this one:

This looks like something anyone can understand; coders and non-coders alike.

You understand where everything starts, what every single function does, and where it all ends (from left to right). This is actually how we think.
“A will call B, and if that succeeds — we will do C”.
So who says coding cannot be done the same way? Who says serverless cannot be done similarly, just the way we picture it?

The product process

All software products go through the same process:

Planning (using a whiteboard or paper)
Architecting (same as #1, or using Google Draw and such)
Implementing (A code editor, various helper scripts and infrastructures, logs sink)
Debugging (Same as #3 + different solutions for errors, monitoring, etc)
Deploying (Deployment scripts, code editors, SaaS solutions, monitoring techniques, logs sink, etc) This is true for new features, bugfixes, refactorings, upgrades and everything else. The same cycle, involving at least 8 different tools, each fulfilling a different purpose, and each billing you at the end of the month.

It doesn’t have to be this way.

In practice — serverless made simple

No more beating around the bush. We want to be able to plan, code, execute and debug all in one place. We want it to be simple, visual, intuitive and cheap.

Getting started

Let’s start by signing up at STATEWIZE.com for a free account.

Planning

We can think of every single thing we develop as a “flow”. Let’s create a new flow, and add some “states” to it. Each “state” is a logical piece which performs an action (if you are from a technical background — this is one “serverless” function).

You can connect states to one another in order to create a flow — where one action would call the next one as soon as it’s done.

Any connection originating at the green 🟩 box will be executed only if the current state succeeded. The red 🟥 box is the opposite — for failures.

Implementing

Since each of the states “does a thing” — we can tell it what it should do. This can be a pre-made action (such as “Make an API call somewhere”), or a custom serverless function we can code right there in the browser:

Executing & Debugging

Once your flow is complete, you can execute it and see it running in real time:

Looking at this, you can understand exactly what happened when, in which order and why.
You also don’t need to worry about logs — every output of every single state is available to you immediately, so you no longer have situations where you are “blind” due to a lack of logs or context data.

Hours which you usually spent on debugging can now be spent sunbathing or watching telly, since this kind of visual debugging allows you instantly spot any issues or bugs without the headache.

Integrating

Using the dead-simple STATEWIZE SDK allows you to integrate this serverless flow into your existing project in just a few lines of code:

It’s done, your serverless flows are up and running in a matter of minutes, and your existing projects can easily invoke them as and when required.

Technology does not need to be exclusive, difficult or cumbersome. Things which can be simple — should be simple. For your life, for your business, for everything. This is the mission which drives us, this is why we do what we do.
Technology done right — means resilience, reliability, stability and calm. Let’s aim for that. 🌅