Maximizing web app's business value through backend revamp | How we do IT #5
People tend to judge web applications by how they look. But the logic that runs underneath determines how much value the product can actually deliver. This "How We Do It" episode from Merixstudio shows how to align backend architecture with business requirements — using a real project where improving the application's internals changed what the product was capable of.
00:00 → 00:01
When it comes to web applications,
00:01 → 00:04
people tend to judge the book by its cover.
00:04 → 00:06
If it's nice and clean on the outside,
00:06 → 00:08
they are keen to use it.
00:08 → 00:11
However, it's on the inside that all the magic happens.
00:11 → 00:15
So today, we'll show you how to marry business logic with technology
00:15 → 00:19
to maximize applications' usability, especially if it
00:19 → 00:21
leaves a lot to be desired until now.
00:25 → 00:26
I'm Aleksandra,
00:26 → 00:28
Senior Content Marketing Specialist at Merixstudio,
00:28 → 00:30
and this is how we do it.
00:30 → 00:34
In this series, we present you specific design and development
00:34 → 00:38
challenges and explain how we deal with them at Merixstudio.
00:38 → 00:41
Every case is based on our own experience and projects we've
00:41 → 00:42
worked on so far.
00:42 → 00:44
In this episode,
00:44 → 00:47
we'll take a closer look at our client from the solar energy
00:47 → 00:50
sector who's based in Western Europe.
00:50 → 00:53
Their application is supposed to help salespeople prepare the
00:53 → 00:57
most accurate calculations and proposals for their customers.
00:57 → 00:59
The product has a lot to offer.
00:59 → 01:02
It estimates energy production and consumption,
01:02 → 01:06
visualizes data and prepares detailed offers for the customers.
01:06 → 01:09
It all sounds great in theory, but in practice,
01:09 → 01:12
the amount of actions puts a burden on the application,
01:12 → 01:15
causing it to work slowly and ineffectively.
01:15 → 01:18
How to make the most of the existing solutions while adding
01:18 → 01:19
value for the stakeholders?
01:19 → 01:22
See how we do it at Merixstudio.
01:22 → 01:26
Let's start with
01:26 → 01:27
the biggest challenges.
01:27 → 01:31
Firstly, the overall experience of the product is rather harsh.
01:31 → 01:34
The abundance of features can empower salespeople,
01:34 → 01:37
but accessing them takes way more time and effort
01:37 → 01:39
than it should.
01:39 → 01:43
Then, onboarding new employees to the tool can be tricky.
01:43 → 01:44
On top of that,
01:44 → 01:47
the company has grown and evolved and so the solution
01:47 → 01:49
stopped meeting users' expectations.
01:49 → 01:52
Sounds like a lot? Well, there's more.
01:52 → 01:55
The second issue is the tool's performance.
01:55 → 01:56
At the beginning,
01:56 → 02:00
the product was basically a spreadsheet with a complex algorithm.
02:00 → 02:04
Simply put, its function was to ensure the precision of the calculations.
02:04 → 02:07
As the tool contains a massive amount of data,
02:07 → 02:09
processing it takes a long time.
02:09 → 02:12
What's more, users access the solution via SharePoint,
02:12 → 02:15
so the environment is not entirely stable.
02:15 → 02:17
Not to mention that a spreadsheet doesn't really
02:17 → 02:19
facilitate the entire selling process.
02:19 → 02:21
Now that you know the problems,
02:21 → 02:23
it's time to learn about the solutions.
02:23 → 02:27
My expert today is Bartek, our Python developer.
02:27 → 02:31
So, Bartek, how about the high level changes in the product?
02:34 → 02:36
Improvement of a product like that should be conducted on a
02:36 → 02:40
few levels as we need to take care of more than one thing at a time.
02:40 → 02:44
Looks are not everything, but in this particular case, they do matter.
02:44 → 02:47
That's why the design work comes first.
02:47 → 02:48
Our app is all about the data.
02:48 → 02:52
So we need to find a way to visualize it properly.
02:52 → 02:55
Almost ninety screens and dozens of video calls with the client later,
02:55 → 03:00
we managed to achieve a cohesive light looking and fast working facade.
03:00 → 03:02
Remember, you make a first impression once,
03:02 → 03:04
so make it a good one.
03:04 → 03:06
Secondly, it's okay for the tool to be complex,
03:06 → 03:08
but not overwhelming.
03:08 → 03:10
An application of this kind needs a lot of features to
03:10 → 03:13
prepare a calculation or an offer for the customer.
03:13 → 03:17
But it doesn't mean all of them should be visible at first glance.
03:17 → 03:20
Plan tools look wisely, prioritizing the essentials
03:20 → 03:22
over the additions.
03:22 → 03:25
A well organized structure and navigation in application help
03:25 → 03:28
keep information architecture clean and consistent.
03:28 → 03:30
And lastly, think long term.
03:30 → 03:33
Because the company and the product will evolve.
03:33 → 03:35
Scalable design is one thing,
03:35 → 03:38
but scalable code is equally if not more important.
03:38 → 03:40
Following coding standards like KISS or YACNE
03:40 → 03:45
and writing clear acceptance criteria makes code lucid and concise.
03:45 → 03:48
It also lays the foundations for possible changes.
03:48 → 03:50
They will consume the new thing.
03:52 → 03:53
Now that you mentioned the code,
03:53 → 03:55
let me ask you about performance.
03:55 → 03:58
How would you boost it in this very case?
03:58 → 03:59
We've been there before,
03:59 → 04:01
so I have a couple of solutions to share.
04:01 → 04:03
To begin with, a spreadsheet may handle big data
04:03 → 04:05
calculations effectively.
04:05 → 04:09
But it's not exactly fit for creating user interfaces or
04:09 → 04:12
sales offers, especially in a growing organization.
04:12 → 04:16
That's why it has to be transformed into custom software.
04:16 → 04:18
Transferring the former solutions logic into it.
04:18 → 04:21
There are technologies that may easily handle the number of
04:21 → 04:25
calculations like Python connected with pandas or NumPy library.
04:25 → 04:26
And they may be a huge help here.
04:26 → 04:29
A clear organized code on the back end will increase the
04:29 → 04:31
application speed and stability.
04:31 → 04:35
Secondly, taking a deep dive into the product's business logic and
04:35 → 04:38
thinking about the best ways to translate it into something new
04:38 → 04:40
is a key in such optimization.
04:40 → 04:44
In this case, we deal with a very good algorithm inside the app.
04:44 → 04:45
We need to treat it respectfully.
04:45 → 04:48
Squeeze the best out of it and elevate it with some good
04:48 → 04:49
technological solutions.
04:49 → 04:53
That's the most effective way of realizing the full potential
04:53 → 04:54
of a product that needs a revamp.
04:54 → 04:56
Last, but not least,
04:56 → 04:59
integrations with external services may really make a difference.
04:59 → 05:03
In a former version of the app, all the data was hidden inside.
05:03 → 05:05
No wonder it tended to crash a lot.
05:05 → 05:08
It's always worth remembering that performance is crucial to
05:08 → 05:09
app success.
05:09 → 05:12
And think about the work optimization for the users.
05:12 → 05:15
Connecting the tool to the external solutions will
05:15 → 05:19
automatically perform actions that users would otherwise need to do manually.
05:19 → 05:20
Sounds like a win win situation.
05:20 → 05:21
Right?
05:21 → 05:23
Now, that's what I call useful advice.
05:23 → 05:24
Thank you, Bartek,
05:24 → 05:27
for walking us through complex back end matters in such an
05:27 → 05:28
approachable way.
05:28 → 05:31
Do you feel like your application could use a back end audit?
05:31 → 05:35
If so, follow our advice and let it shine brighter than ever.
05:35 → 05:39
Thanks for watching and see you in another how we do it episode.



.avif)

.avif)
.avif)
.avif)