A slightly different post today, rather than delve into the new features in Agilebase (which we’ll have to do soon as there are quite a few!), we’ll take a step back and look at the entire journey of a No Code project. From when you start as a new customer to years down the line, with a particular focus on how you can wring the most value out of a project.

We’ve a rather unique perspective, as we’ve seen many different types of project succeed (and yes, one or two fail), taking different approaches, with different people.

However as a customer, you are at the coal face searching for seams and hitting the wall with your pickaxe, if I can overdo a metaphor. You no doubt have your own opinions and experiences of what works and what doesn’t. I’d love to include those into the best practices we recommend, so please chime in.

For non-customers, I think most of this will be relevant to any No Code project, but some of it will be specific to our own technology platform, Agilebase. If you have your own general project management experience, feel free to respond with your thoughts too.

Summary

A general phrase to encapsulate our goal is ‘sustainable value delivery’ and we’ll include five themes to work towards that aim:

• user engagement (work with, not for people)
• enhanced development (using AI to help beginners)
• architectural integrity (ensuring what’s built lasts and doesn’t have to be completely re-written)
• value streams focus (focussing on specific goals which matter, one at a time)
• time to value (one of the main advantages of No Code: not having to wait months for payback!)

Sustainable No Code success = speed + structure + people

A Prerequisite

It’s worth separating out one thing in particular, after which there’s a go/no-go decision.

That is simply allocating time.

It sounds obvious but you’d be surprised how often prospects come to us with a great vision and plan for new processes and technology to improve their business, but also say “we can’t spare anyone to take ownership of this, please just do it all for us”. Sometimes I admit we have been tempted to try, but I don’t think any of those projects have lasted more than a few weeks.

That leads to a key decision – who is going to organise and do the work?

Now to be fair, it is completely reasonable for an organisation to want to focus on their core competencies and outsource development. In fact there are good ways of doing that, which I’ll come to in a second. Indeed there is a continuum of options, from light touch to fully in-house. Let’s take a quick look.

Light touch

Pretty much by definition, any No Code project will be developing apps or processes which are unique to the business. Otherwise, why would you use no code? You’d probably find something off the shelf. For instance, I’ve never heard of an accounting app being created for a company with No Code – accounting rules are fixed and apply to all, for good reason!

You’ll either be developing something completely new, or putting your own twist on how you do business – precisely to give yourselves a competitive advantage.

In other words, you are the experts in how you do things. You need to be able to allocate time to at least explain your work and test results.

To help, we have a network of experienced partners, experts in both project delivery and in particular the Agilebase technology. You will need to have regular and frequent meetings (including virtual) with them. Scheduling and budgeting these at the start will be a great help towards getting good results fast.

In house

Another exciting approach is to learn some new skills and roll your sleeves up yourself (or choose someone in the business to). This might sound time consuming and therefore expensive, but bear in mind two things:

Firstly, AI-supported no code is designed to get results fast.

Secondly, you don’t need a particular technology expert and therefore an expensive person. Rather, you can choose someone within your company who is maybe an under-utilised admin person, transforming the value you get from them. They don’t need to have a technology background, but if they at least have worked with spreadsheets and are able to think clearly and logically, they’ll be ideal. Many people who’ve gone down this route and followed our learner progression programme have advanced their careers and automated away the boring work they used to do!

You’re welcome to blend the two approaches, working in house but taking advantage of a partner’s knowledge, at the early stages to ensure what you’re building will last and later on to help with any complex areas which might come up.

Getting Started

The first theme we mentioned was user engagement.

Just like any project, it’s crucial to involve all stakeholders early on. That includes the people who will be using the new software.

There is hopefully some excitement about a vision for the project, but for software projects in particular, there’s often also some scepticism, not unwarranted given the success rate of new software projects in general. It’s also due to the fact you can’t see or get a feel for how the system will be to use before it’s built.

No Code has the unique ability to tackle those concerns head on.

We always recommend an initial prototyping event. Everyone gets together in a room (or on screen for remote workers), including anyone who will interact with or benefit from the software but also people who might challenge the ideas or benefits.

Then we do a quick prototyping session, when we brainstorm some ideas, pick something small and prototype it. The goal is not to build something real which can be used long term, it’s just to show the platform capabilities and demonstrate the speed of development.

Here the AI-supported development is invaluable, both to help brainstorm and to create a working application in just a few minutes.

That’s the time when people tend to ‘get it’ – not when it’s explained to them in sales meetings, but when they experience it themselves and see something building up before their eyes.

Once you have that initial buy-in and at the very least understanding, you can start to have proper conversations about what’s possible, what’s most valuable etc. – the who, what, why and when of the project.

Value streams

Now you can step back, outline the whole project, work out what the concrete goals are and who benefits from them.

As an example, one of our customers (R-Tech Materials) runs a business which performs testing on industrial parts. There are four main types of test they do, each of which results in a detailed report to give to their customer. These reports were taking a long time to prepare, check and send out.

Rather than tackling everything at once, the Agilebase partner working with them (Little House Consulting) wisely proposed working on just one of these types. The value identified was the production of the report. Then they could work backwards and find out what would be necessary to be able to automate its production.

In general, you can

• Map Value Streams: Identify the key processes that support business goals: invoice processing, employee onboarding, procurement, etc.
• Prioritize End-to-End Processes: Focus on automating complete flows, not isolated tasks. Partial automation often leads to new inefficiencies.
• Think User-Centric: Design from the perspective of internal users first — ask how the system can make their lives easier and their work faster

All the while, remember not to over-engineer:

• Set a “First Value” Milestone: Define what “value” means for the project early on — whether it’s automating a manual report, speeding up onboarding, or improving customer query responses — and aim for a visible, working solution within a month.
• Start Small, Expand Thoughtfully: Instead of trying to build the perfect system from the start, deliver the minimum viable process that proves the concept and shows business impact.
• Measure Early Wins: Use metrics tied to the value stream (time saved, errors reduced, customer satisfaction improved) to keep business sponsors engaged.

The nitty gritty

As the software takes shape, we come to the main concern specific to Agilebase as a No Code platform.

What sets Agilebase apart from many other tools is its ability to keep going and develop what end up as totally all-encompassing applications for the business, which scale to masses of data and users and automate all the intricacies and complexities of the organisation. We tend to say there’s a very high ceiling for what you can achieve.

What this does mean is that the system can evolve from something very small and simple to a much larger beast.

We need to ensure that the architecture is appropriate and able to deal with what might be coming, from the start, otherwise you might find yourself needing to rip apart and re-build, which no one likes, least of all the people now relying on it!

It’s here where an experienced partner can particularly be of help. They’ll have expertise to draw on and know the pros and cons of the many different approaches you can take.

When we say architecture, when it comes to Agilebase, a large part of that is to do with planning the structure of the database. To use a couple of technical terms, we need to consider normalisation and reuse.

Normalisation

means the extent to which data is separated into different tables. Take for example a list of contacts, which you might have in a spreadsheet. There are columns for

Organisation Name, Address, Name, Email, Job Title

In a database, you probably wouldn’t have these in a ‘flat’ single table structure like that. After all, there are potentially many contacts you can have at the same organisation. Having to repeat the same organisation name and address for each of them would land you in a pickle. Over time you’d probably end up with inconsistent data – lots of organisation names, some capitalised, some not, some with ‘Ltd’ on the end etc.

So we normalise by separating out contacts into a separate table. Now you can have one organisation and many contacts linked to it.

What about if we have many different types of contacts – maybe staff members, contractors, customers, volunteers etc., each with different things we want to track about them? We could have a table for each, but the normalised way would be to have one table storing basic contact details, with others joined to it to store the additional fields needed for each.

It is possible to over-normalise as well as under-normalise. Over-normalising makes user interfaces more complex, under means they can’t deal with the real world.

There’s no right answer to fit every situation – that’s where the experience comes in.

However, AI can also help during the early design phases. Novice users can have discussions with an AI about what the most appropriate database structures for an app might be, given its purpose, who will be using it etc. Agilebase’s AI can also generate example schemas from a prompt, which you can tweak until you have something you like the look of.

Reuse

simply means not repeating the same calculations again and again. If you have many different reports which use your total sales for example, calculate that figure once and just reference it in the different views. 

We’ve just recently added a feature to make this more easy, news of that will be coming soon.

The whole architecture

Summarising the above and bringing in some other key pillars:

Standardize Naming Conventions: Agree early on how you name fields, workflows, and apps to make the environment scalable and navigable.

Normalise: Identify common components (like user profiles, address structures, or approval flows) that multiple apps can share.

Centralize Core Data Models: Avoid each project team creating its own version of “Customer” or “Employee.” 

Govern Access and Permissions: Use roles to ‘normalise’ permissions in the same way. Don’t give the same permissions to 10 members of staff, put them in a role and treat them as a whole. Use the minimum permissions necessary.

Integrate: Don’t reinvent the wheel. As your system grows, you may find it makes sense to integrate with other apps rather than building everything. Agilebase auto-creates APIs to allow you to do that easily.

Share the load

As a system grows and becomes mission critical, the business owners will want to make sure that it will be supported whatever happens.

Encourage more than one person in the organisation to become a No Code software architect. Some of our largest and forward thinking customers have used the built in Learner Progression system to gradually train up new people over time.

Internal documentation can also help here – we definitely recommend adding help to fields and views as you go for example, but also keeping records of your main design decisions. We’re working on AI tools to help here too.

Please let us know your own experiences. Does anything from the above jump out at you? For me it’s the phrase ‘Start Small, Expand Thoughtfully‘, which I think encapsulates the central message.