Written by Shanice Stewart-Jones

‍

Here at Makerpad, we love sharing real-world stories about people who are doing exceptional things with no-code.

So naturally, when we came across this tweet, suffice to say it caught our attention 😉

‍

‍

Daisy Onobogu is Head of Network & Community at Backed VC, a people-focused and community-driven seed stage fund based London, UK. Earlier this year, she tweeted that she’d built an app, using Glide, to better manage the intro and networking side of Backed’s ops.

On first glance (and on diving in), the app looks super slick, incredibly useful, and also kinda beautiful.

We caught up with Daisy to find out more about the app, how she built it, and what it’s changed for everyone at Backed.

‍

Good to have you here, Daisy! Talk us through who you are and what you do at Backed.

Backed’s mission is quite simple — to find exceptional founders, and back those founders.

A big part of the reason I joined Backed in the first place was this idea about community being at the core, and wanting to be human centric, ideally, at every point in the lifecycle of a fund. That includes how we go about sourcing, how we do diligence, and importantly, how we actually support founders post investment.

Initially, Backed were interested in me helping build a scout program — more or less a copy-paste job of what had been done on the West Coast with Sequoia. But I immediately knew this approach wouldn’t work for us.

Aside from that model not supporting genuine community growth (find people and early stage companies, invest, rinse, repeat), it wasn’t a model that was going to work for us practically, being a small fund.

My role is, admittedly, one of those nice, make-it-up-as-you-go roles. So I’ve taken it upon myself to work on incentivizing our people by genuinely building from start to finish an amazing experience — one that has a sense of belonging at its core, but also real tools and resources that make the difference for people.

‍

So what's the purpose of your app? What gap were you trying to fill by building it?

We realized early on that the community we’d built could deliver value outside of deal flows. This could happen in two ways — first, by founders in our portfolio companies being able to take full advantage of our network.

It’s definitely a perk that should be available for founders taking capital from an institutional investor. But it wouldn’t really happen if our network wasn’t visible to our portfolio. This app really makes those connections possible.

Secondly, the app helps us better leverage what I think is the most — if not the only — valuable asset to a fund outside of capital: its network.

Network typically isn’t fully understood, utilized, or engaged with in an intentional way, and a big barrier to that is just data. To better understand the density of our network, the activities that are happening, and help build processes to better take care of our network — that’s the need this app is serving for us internally.

The very first version of our data was just a Google spreadsheet.

‍The sheet was simply a number of columns for different data, like names, where someone worked, the strength of the relationship that person had to the person within the fund, etc.

But there was little-to-no uptake/use of the sheet because if I’m honest, the user experience was garbage.

We tried using Affinity (our internal CRM), which felt more convenient since that was where so much of our data was already stored in terms of who we interact with. But you can't access Affinity unless you have a seat and that just wasn't quite right for us at that time.

Which brought us to the app.

Because we'd already done so much work to gather the data and create the sheet, building an app from it was almost a no-brainer. I’m so happy I found Glide just by accident.

People at work thought building an app in-house was a crazy idea, but I believed it could work.

‍

How does the app work?

It's relatively straightforward. There are two types of user views: one for non-Backed team members, and one for team members.

For both views, there’s one homepage that has multiple buttons/tabs for what I thought were the most intuitive categories based on what people will most likely be searching for in the app.

‍

‍

From there, for the non-Backed member view, each tab you click on goes to a sub-category page where people in the network are tagged and listed based on their demographics — accelerators, incubators, or early stage investors, for example.

And then on each person’s profile there's a bio, and a note of the person within Backed that knows them and could make the introduction. There's also this kind of relationship barometer, which tells you if this person is a cold acquaintance, a warm acquaintance, or friend etc.

‍

That’s a cool feature! Can you walk us through how that’s calculated in your sheet and pulled into the app?

So we have a ‘Relationship Strength’ column within the ‘Contacts’ table of the sheet:

‍

‍

And within that column there are 4 options: cold acquaintance, warm acquaintance, friend, and Backed community.

Every week, Backed team members add people they’ve engaged with to the sheet.

I use a formula in my sheet to calculate a relationship score, then the score is displayed in the app using Glide’s ‘progress bar’ component.

What’s your favourite feature of your app?

I love the feature that lets users request an intro.

The first version that I was going to push out would have just had the contact information visible. But I realized that anything requiring people to jump out of the app just wouldn't really get used, or if it did, then not meaningfully.

So I wanted to make it more hassle to look for an intro in any other way than by using the app!

When you click on ‘Request Intro’, from there you have your contact’s information, and the information for the person you’re requesting an intro with.

‍

‍

You can type in some context and attach a file if needed.

I wanted to make it really seamless for the person forwarding on that intro request (Pascal, in this instance) to make the request, so that they wouldn’t really have an excuse to not do it.

So how I set it up is that when that intro request comes through, for example to Pascal, he will now see the request in his user profile in the app, and he simply has to swipe right when viewing the request to send it on to his contact.

‍

‍

This means if someone has a batch of requests to forward on, they can do so quickly and without hassle.

They can also swipe left if they want to customize the request or make other changes.

Other fun features include being able to shortlist contacts until you’re ready to request intros with them, and a partnerships/deals/offers tab with various offers that people can claim.

How is the Backed team member version of the app different to the non-team member version?

The app is similar in terms of viewing contacts and requesting intros for yourself. 

But one difference is that as a team member, you can make an intro request for someone else. Sometimes people on the team want to make intros for or on behalf of our portfolio companies, so this feature really helps there.

I’m really encouraging everyone to use the app for intros and making contacts rather than doing it outside the app. This means that we can all see what’s happening overall across the network, to give us a good idea of how people are connecting, how they’re adding value, who we should be taking care of, etc.

‍

Does this app you’ve built integrate well with your Affinity CRM?

It does in some ways. We use Zapier, so we’re limited to what zaps we can make there, and I haven’t yet found a way to integrate beyond those zaps.

Something that’s proved very useful is being able to track deal flow — so pulling deals from Affinity and seeing that data in the app. This tells us who is sending us deal flow and where it’s coming from, and what proportion of the network is sending deals to us.

Do you have any other tools in your tech stack outside of Glide, Google Sheets, Affinity and Zapier?

We use Mailchimp for sending emails and Airtable to house some data, but that’s for another app we have and not specifically for this one.

So really, this whole app runs on four tools: Affinity for deals and member info, Google sheets for re-organizing and displaying the data, Zapier to connect the two, and Glide to build and host the app.

How’s the app been received by everyone using it?

It's been really good, actually. The team is obsessed and over the moon, and the portfolio is excited.

And I think I’ve felt more motivated to build lots of cool features because the portfolio’s been so happy and excited to use them. Sometimes rolling things out in the past has been an uphill climb, but not with the app. And that’s great.

‍

Do you think a no-code app will always meet your needs, or do you think you might need to go down a developer route one day?

As far as I can see, no-code will be enough.

I think I definitely have to get someone involved at some point, because the amount of builds that needs to happen is increasing all the time, especially as there are two apps on the go.

But for the most part, I haven't come across anything I want to do for which there’s an obvious limitation in a no-code tool’s ability.

If that changes, then fair enough. But I really don't think that will be the case. I think it's more a matter of time and energy and effort! We shouldn’t ever need to build a “real” app, and that’s really cool.

This is a real app!

Ha, yes it is.

There’s also a huge advantage building this way, without code, in being able to stay in the loop and still have control over it all. I’m a control freak! So this way, I can still draft people in to help, but if I want to go and fix something or change something, I can.

It’s amazing to see what you’ve built from scratch. Do you have any advice for people who might be keen to do what you’ve done but aren’t sure how or where to start?

I think the best advice I can give is to start with the ugly version of what you want to build. If you can conceptualize that, then you’re off to a good start.

If I’d have thought about the pretty version of our app with all its different components, it would have been impossible to get my head around how to achieve it.

Whereas if you just focus on answering questions like: what am I trying to fix, and what would be the ugly version of solving this? You’ll do much better. You can start building your ugly version and imagine that’s your final output. You can start with a spreadsheet and use that as a baseline to feed into different tools that will help you build what you need.

The same goes for non spreadsheet based ideas too. Even if you’re building in a tool like Bubble — just think what the most basic version could be.

This is also true for any process, really. It helps to just think about what it is you’re actually trying to get done, map that out, and don’t even think about how you might scale it. Just stay super rudimentary.

Once you’re ready to move on past this phase, asking other people and carving out time to play around are two things that will be really helpful. When you’re up against a deadline, you’re only going to use what you know, so setting aside time to experiment and explore is the only way you’ll really figure out ways to take your projects further.