Journey to low code 3

1. Credit: Vaibhav Vaidya, 2023
https://www.linkedin.com/in/vaibhav-a-vaidya/
Choosing a Tool(s)
Your journey to Low-code: Step 3
Abbreviations:
LCP = Low Code Platform
LCT = Low Code Tool developed on an LCP

2. a. Key Metrics

3. Define measures of success
The
fi
rst step is to put down any must-have or nice to have
improvements that you will expect from your transition. Some
examples are:
• Code-liability reduction ratio (200x in one instance for us)
• Cost saved on consultants or developers doing maintenance
- important for tools where stability of old code is the key
concern
• Time-to-market for new features - important for LCTs
intended for fast-evolving parts of the business
• Number of tools owned by a single developer - LCPs can
expand the ability of one developer beyond a single tool to a
larger part of the stack
• — Or, what do you expect from low-code adoption?
Make sure to revisit these KPIs during the execution and review

4. b. Narrowing the list

5. UX customizability
Do you really need to control the pixel size and position of every button
and text
fi
eld that the user sees on every screen individually? Will most of
your users use a particular device form factor or switch between them?
Low-code platforms can provide a huge advantage in time to market with
standard, good looking UX experiences that work across device form
factors (e.g. AppSheet) or templatized yet fully customizable setups (e.g.
Bubble).
LCP UX experiences can vary considerably on their central forming ideas.
So to maximize return, pick one that already looks like the one you want
to see e.g.
• Want something that looks like a spreadsheet and lets you
fi
lter / add /
remove columns / rows easily, but don’t care about responsive design
as much? => Use Ninox
• Don’t have a spreadsheet focus but want a tool that easily switches
between list/detail/form views with consistent UX across all tables and
built-in responsive design? => Use AppSheet
• Do you need to control the brand experience fully but need re-usable
components to speed up UX development? => Use Bubble

6. The shopping experience
While the criteria are speci
fi
c to your use case, we also
recommend that you consider:
• LCP vendor stability - is it a high-risk startup?
• Will you accept the risk e.g. for key emerging
technology functionality?
• Support experience
• Are there ratings for LCP support team?
• How knowledgeable and prompt were their
technical sales team?
• Is there a close-second that you might choose in case
your primary LCP choice falls through?
• What would be the switching cost?

7. The shopping experience
It is important to write out a full comparison before picking
favorites! On more instance than one, we ended up not
choosing the platform that seemed like the obvious rst
choice.
#Pro-tip: Don’t
focus on an
exhaustive
comparison with
each box
fi
lled.
First look for
critical no-gos
for quick
shortlisting. See
examples in red
#Pro-tip: Learning
resources:
https://
www.nocode.tech/
https://
nocodelist.co/

8. c. Committing to one
or more LCPs

9. Create a business case here
After going through your comparison table and picking favorites, start
by revisiting the split of full-code vs low-code parts of your new stack.
Elaborate on why each choice makes sense when compared with the
old stack. Make a case for the new stack:
• What’s your expected cost vs expected key metrics performance?
• What pitfalls did you verify and how did you calculate scale?
• What metrics do you expect to improve?
• Which stakeholders are impacted?
• Will UX change for sta
ff
/customers?
• Will your team structure be impacted?
• Will external vendors be impacted?
Finally, include an execution plan as with any major change - the
timeline including cost change milestones, cutover/rollback plans, risk
factors and mitigation. Some notes speci
fi
c to a low-code execution
transition impact on a dev team are noted in the next slide set.

10. d. Use-case examples
*Speci
fi
c claims about tools made in this article might change, as the
tools evolve quickly! Please use the structure but check the content.

11. Team task management tool
Scope:
5 people need to manage design tasks e
ffi
ciently. Scope may
expand to include making sub-tasks and projects. The tasks
should also act as a type of documentation on the project
Key features:
• Small user base with minimal costs and scale limited by
human content entry
• Uncertainty around full feature set, and the need to build-
as-you-go
• No requirements for user roles or data protection
Tool of choice:
Notion (with close second Coda)

12. Customer app with Branded UX
Scope:
App that re
fl
ects company brand and used by customers, downloadable
from android app store as well as available on the web with responsive
design and built-in user management. Connecting to full-code backend via
API that serves dynamic content. Need to prototype backend quickly
before deploying scale backend. Customer scale is ‘unlimited’, use of the
app makes money.
Key features:
• Full control over user experience, economies of scale (no per-customer
costs of deployment but workloads make money)
• Native mobile app as well as web, responsive
• Full-stack capability with
fl
exible backend
• Consume dynamic content from API backend
• User management
Tool of choice:
Bubble (With close second Flutter
fl
ow)

13. Migrate and scale CRM from Google sheets
Scope:
Initial customer base in Google sheets for
fi
ntech app needs to
scale to 1000’s of customers and 25 sales sta
ff
to see only their
customer deals. Potential international multi-locale expansion.
Google Workspace integration important.
Key features:
• Per-user costs to scale with sta
ff
, not customers
• Out of the box Google Workspace integration would reduce
time to market and maintenance-overhead signi
fi
cantly
• Potential data migration to Postgres
• Data-partitioning and A.C.I.D. compliance paramount
Tool of choice:
AppSheet