9
2 Comments

LowCode, start here

low code

It's no question that low-code or no-code platforms are 1 of the disruption technologies for the past 2 years or more and will only gain momentum going forward, which is exciting because they raise the level of abstraction in tools. Tools that reduce cost and improve productivity in the right way.

Large organizations are buying up low-code platforms and making it part of a larger offering, AppGuyver bought by SAP (I think), Mendix being bought up by Siemens, and many others sprouting up all over the place so it's no surprise that there is something there ito market.

When covid started, I got into a bunch of DDD topics and started playing around with React as well and thought of combining these high-level topics with React, using other lowcode platforms as inspiration, minus their deficiencies that comes from legacy codebase or thinking a-la Conway's Law. A new dispensation requires new organization.

Right now, I am building that platform, it is declarative in nature, aligns itself toward DDD thinking and other high-level abstractions built on top of React, GraphQL, NodeJS and would like to share the adventure with you here.

There is a fair bit of it already built, I'm at a 3 iteration and find it very promising, but a SaaS isn't just the core product, but all the other features and services around it too and all of that takes time.

Most of the build process and infrastructure is already automated via Azure DevOps and hosting on a Linux host, but a lot of the evolution, testing and architecture is done by myself, which is too many hats for 1 guy.

This is where I need help, there are only 2 hands and 2 eyes working on building this service, but I think it's time to onboard some help to go faster and complete something that's already pretty darn cool.

Hit me up if you are interested. I need help with Graphic Design or UX of a SaaS, React development and helping to complete features or the core product, Payment gateway services for subscription and then Marketing, probably lots of it. I've managed to outline a couple of business cases, but still need to pick the ideal model. I can always showcase a demo.

Think win-win, if I can help you potentially, just ping me and we'll talk.

  1. 3

    I'd like to call this post "the history of shadow IT"...

    I've worked in corporate a while, and when business folks aren't able to get their problems solved with legit IT solutions, they typically default to building "shadow IT" solutions. These solutions usually turn out to be some sort of combination of spreadsheets, recorded macros, and someone's attempt at building an Access database. The piece de la resistance is they put the whole thing on a sharepoint site. It's usually a horrid mess for IT to come in and clean up later, usually when there is some IT-sponsored upgrade, and the duct tape solutions no longer work.

    There was even a time a few years ago when certain business teams were actively hiring for "shadow IT" roles, a la looking for an individual who might be considered a "power user" ... this role would sit on the business side, but their function would be to create technical one-off shadow IT solutions which were not sponsored by IT. This practice was shut down soon enough and lots of processes were spun up to monitor hiring practices and monitor business operations to prevent shadow IT solutions from being implemented.

    Now before you go thinking that I am a snobby IT exec, the other side of the story here is that the whole reason "shadow IT" became a thing is because IT simply wasn't delivering. Simple as that. Business had been burned too many times with IT promises that never materialized into an actual, workable solution with business value.

    In 2021, it looks like "shadow IT" has re-branded itself to "no code".

    So I wonder if the corporate purchases of all of these no-code solutions are really just another attempt to shut down the "shadow IT" solutions? As they stand now, these types of solutions will never be accepted in corporate fortune 500 (other than to be used in prototyping), so is this a way of eliminating solutions before they get a foothold in the corporate marketplace?

    I ask these questions because I don't really don't know if there is a market for no-code solutions, other than a prototype or a 1 or 2 person side-hustle.

    Thoughts?

    1. 1

      I think you make a few good points. It is funny how relatable these kind of problems are, as in my experience from working in South Africa is the same and also here in Canada.

      In many cases these products were brought in because of the inability of IT to perform. Business was interested in generating business value, whereas IT's responsibility is to be the enabler to achieve that, but in truth their interest lies in proper architecture, design and implementation which usually takes time and implicates hidden costs that is sometimes hard for business to understand 100%.

      The phenomenon of "Shadow IT" or in this case low-code exists because of an impedance mismatch that exists between these 2 worlds. Sadly, as you explained, these tools usually get botched up in the long-run, or rather IT eventually has to inherit the mess created by them and usually with a large technical debt attached. All that is to say, there is a reason business does what it does when it makes these kind of decisions and we should not ignore that, instead we should address it and I think low-code is a viable pathway.

      All "low-code" implies in this context, is that the implementation is hidden, and therefore only leaves you with the high-level DSL or layer of abstraction for sophisticated users to "assemble". Low-code doesn't mean no-code in all cases. Like Mendix does, they make the distinction between "Studio users" and "Studio Pro users", meaning IT still extends the base product, but the implementation is still hidden from your "studio users".

      If we ignore "enterprise use cases" or fortune 500s and instead focus on the global audience, there is a spot for low-code in SaaS form. In some cases this is a sufficient business model for a small companies. You may not end up in the fortune 500s right now, but you may be entering the grassroots for future fortune 500s if your business model can evolve with early adopters, with an eye on long-term growth as opposed to gaining the market immediately.

      That being said, I think that there are some deficiencies in low-code offerings today , for instance testing frameworks or rather the best practice of testing before releasing and many other such cases over which IT usually governs. These deficiencies however is a market opportunity and not an impediments per se, if done correctly.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 15 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments