Introducing our Fictional Start-up

By

,

Meet Dave, who has recently joined the Geovation tech team as our Full Stack Developer! We’re delighted to have him onboard; his wealth of knowledge and experience has been a true asset to the team already. He’s shared with us a sneak peek into what exciting things they’ve been up to in the tech team below.


Want to find out more about our Tech Team?

Sharing our knowledge with start-ups on how to make the most of Geospatial data is a key part of our role as the Tech Team at Geovation. We frequently find ourselves sharing the same code samples or tutorials to act as a guide on how to approach a problem. But these often feel isolated from the real world.

Code samples rarely translate into solving actual problems that a start-up may face. They also don’t always relate to the technology that a start-up would choose, if following an industry standard approach. So, we asked ourselves ‘how can we make these things relatable and useful to our members in the Geovation community?’ To which our best answer was to create our own fictional start-up, with its own product offering!

A fictional start-up

Wanting a theme to link our examples and give start-ups some context, we considered the examples as something that a genuine start-up would do. Where the integration of a technology or dataset would directly enhance their product.

That allowed us to immediately adopt the following principles:

  • Choose technologies and tools wisely. It’s not worth being saddled with legacy technology when starting out. At the same time, we don’t want to try new tech for the sake of it. Small businesses need to weigh up implementing the latest technology with ensuring that they are adopting ‘tried and tested’ solutions. It’s also important to adopt technologies that are reasonably popular so that people can be found to maintain and develop with them.
  • Avoid cutting corners. Tutorials will often skip inconvenient problems. If an API requires you to not reveal your API key within the web browser, then we can’t write a tutorial that does this while saying ‘make sure you don’t do this in a real app’. What we create should be possible to use in a production app.
  • Demonstrate best practice. It’s not good enough to just provide something that works but doesn’t have any longevity. We can’t promise that our examples will be free from bugs, or mistakes. Yet, we’re also not just creating throwaway code that simply demonstrates an idea.

Initial idea

Our fictional start-up was born. Introducing our full-stack example mapping application that we’re developing, UseMap. UseMap will demonstrate the elements that go into creating a software application on the web, on mobile devices, and as a desktop application. With features to provide insight into buildings and building usage across different geographies in Britain (statistical, governmental, social, and economic). Like many start-ups, we’ll be looking at creating a proof of concept that provides enough features to feedback and validate the initial idea.

Realistically and unfortunately, this will never be exactly like a start-up. As the end-user of the product is the Geovation community, rather than imaginary users. Despite this, by following the principles we’ve adopted we hope to be able to demonstrate a lot of key features.

  • A Flutter app. Still a relatively new technology, Flutter has recently surpassed React Native as the most commonly adopted cross platform mobile app technology.
  • A PWA (progressive web app) using ReactJS. This is still one of the most widely adopted frameworks that provides one of the quickest routes to publishing your application on the web, using component libraries such as Material UI.
  • Backend services using Flask and Python. Within the Geospatial community we still see a large number of people using Python. Flask is a lightweight framework for creating backend microservices using Python.
  • Cloud computing hosting and services. AWS leads in the cloud market but this market-share is gradually reducing. We will continue looking across cloud providers.
  • A mix of self-hosted and commercial map services. In many cases, start-ups will need the quickest solution available. This may mean implementing API and tile services from commercial cloud providers. In other situations, it can save on costs to self-host solutions based on openly licensed data. We will showcase both options. We want to try and use No-code solutions where we can.

What do you need?

More useful than any of this speculation will be hearing from our own community. Are you thinking about using Flutter and want more information about it? Is there an API or dataset that you think you may want to use but aren’t sure about doing so? We’d love to cover areas that are most useful to our members, and to get feedback from you.

As ever, please get in touch with Myself (Dave) or Lewis on Slack to arrange a tech clinic, if you have any queries or want a chat!

Want to stay up to date with UseMap? Sign up to our Newsletter or follow us on socials to hear the latest developments!