Skip to main content
Geecon Global

Business application development

Bespoke databases for data that has outgrown a spreadsheet

When operational data matters enough to protect but still lives in a shared file, the risk is not theoretical. A proper database makes it safe, queryable and shared.

Free consultationNDA on requestReply within one working day

Trusted by global clients and organisations

  • Cisco
  • Blackbaud
  • Compassion UK
  • Oracle
  • WSBC Bank
  • Essar
  • Port of Algoma
  • WSD
  • Headlines Advertising
  • T&S Heating
  • Marsham Court Hotel
  • Cubot
  • Equel
  • Fairhaven Healthcare
  • Great Step
  • FindUsOnWeb

The situation

Data too important to leave in a spreadsheet

Spreadsheets are excellent tools that make poor databases. The trouble usually appears at exactly the point the data becomes valuable.

  • Several versions of the same file, each slightly different
  • No record of who changed what, or when
  • Formulas that break when a row is inserted in the wrong place
  • Access controlled by who has the link rather than by role
  • Reporting that means copying the data somewhere else first
  • A file that has grown slow, fragile, or both

What it covers

What a database build covers

  • Data modelling

    A structure reflecting how the business actually relates its information, designed to survive the next five years of change.

  • Validation and rules

    Constraints that make bad data hard to enter, rather than a cleanup exercise later.

  • Interfaces

    Forms and screens so people can work with the data without needing to understand the schema.

  • Access control and audit

    Roles, permissions and a record of changes — necessary as soon as the data is personal or financial.

  • Reporting and export

    Queries and reports built in, so an answer does not require a developer or a spreadsheet.

  • Migration

    Existing records moved across, with duplicates and gaps surfaced for a decision rather than carried over silently.

How we work

How a database project runs

  1. 01

    Understand the data

    What is held, who uses it, what decisions depend on it, and what it is expected to become.

  2. 02

    Model and design

    Design the structure, the rules and the access model before anything is built on top of it.

  3. 03

    Build and migrate

    Build the database and interfaces, then move existing data in a rehearsed migration rather than one risky cutover.

  4. 04

    Hand over

    Documentation, training and support, so the system does not depend on whoever built it.

Outcomes

What you are left with

  • One authoritative version of the data rather than several files
  • Validation that prevents errors instead of reporting them afterwards
  • An audit trail showing who changed what, and when
  • Access controlled by role rather than by who holds the link
  • Reporting from live data, with no export step
  • A structure that can be extended as requirements change
Software development lifecycle loop: idea, architecture, prototype, development, testing, deployment, monitoringIdeaArchitecturePrototypeDevelopmentTestingDeploymentMonitoring

Platforms and tooling

What we build with

Relational

  • SQL Server
  • PostgreSQL
  • MySQL
  • Oracle

Other stores

  • MongoDB
  • Redis
  • Elasticsearch

Hosting

  • Microsoft Azure
  • AWS
  • Private cloud
  • On-premise

Named as platforms we work with, not as formal partnerships.

Questions we are usually asked

Yes, and that is usually where the project starts. Migration is where most of the risk sits, so it is rehearsed rather than done once at the end, and inconsistencies are surfaced for a decision instead of being silently imported.

No. The database is the foundation; what people use is an interface designed around their task. If a user has to understand the schema, the interface has not been finished.

A properly configured one usually is, and is generally more secure than a spreadsheet on a shared drive. Access control, encryption and audit are part of the build. We will work to your data protection requirements, though we do not give legal advice on compliance.

They will. That is what the design stage is for — a model built around how the business relates its information tends to absorb change, where one built around today's report does not.

Yes. A database nothing else can reach just creates a new island, so integration is normally part of the scope rather than a later project.

Backup, retention and recovery are agreed as part of the build and then tested. An untested backup is a hope rather than a plan.

Talk to us

Talk to someone who has built this

Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.

Tell us what you need

No obligation, and nothing is shared outside Geecon Global.

Not sure where to start?

Fields marked * are required. We use your details only to reply to you. See our privacy policy.

Build smarter, scale faster