Oogle

BUILD

When what you need doesn't come as a plugin.

Portals, calculators, quoting tools, member areas, internal systems, and connections between software that was never meant to talk. Built to your requirement and yours to keep.

THE MOST USEFUL THING TO BRING

Not a specification. A description of what somebody does by hand today, how often, and what goes wrong when they get it wrong.

What this covers.

Customer and partner portals

Where people see their own documents, orders, jobs or invoices instead of emailing you.

Calculators and configurators

Pricing and specification tools that turn a phone call into a qualified inquiry.

Quoting and application forms

Multi-step forms with conditional logic, file upload and saved progress.

Member areas and gated content

Access rules, tiers and downloads that are genuinely protected, not just unlinked.

Internal tools

Scheduling, job tracking, reporting and approvals. Often the highest-value work we do.

Connecting two systems

Where one holds the customers, the other holds the jobs, and someone retypes between them.

  • PHP 8
  • JavaScript
  • MySQL / MariaDB
  • REST APIs
  • Webhooks
  • OAuth
  • WordPress
  • Drupal
  • Custom applications
  • Queues
  • Cron
  • Git
  • Staging environments
  • Structured logging

How we keep custom work from becoming a burden.

Build the smallest thing that solves it

Custom code is a permanent responsibility. Every feature is something to secure, update and eventually explain to somebody new. So we build the smallest thing that genuinely solves the problem, and skip the features that sound good in a meeting and get used twice.

Built to be handed over

The code goes in your repository, credentials are in your name, and the documentation is written for someone who's never met us. Nothing depends on a service only we can run.

What to expect

  1. We watch the manual process first
  2. We separate the requirement from the solution
  3. We define what done means, in writing

For anything substantial we usually suggest a short paid review first: we look at your systems, define what done means, and produce a scope with a real figure.

How we bill

Custom development questions.

How do we know the estimate is realistic?

Because it's based on reading your actual systems rather than talking about them. Where we can't see enough to be confident, we'll say which part is uncertain and why.

Can this connect to the software we already use?

Usually. It depends what it exposes: a documented API, a webhook, a file drop, a database we can reach, or nothing at all.

Who owns what you build?

You do, on work billed as a project: your repository, your hosting, your accounts, once it is paid for. Custom development is always scoped and quoted, so this is the arrangement it runs under.

Quoted Services

This is the third path, and it is most of what we build.

Quoted

Quoted after we look. One-off or monthly.

Not what you need? See all three ways we work

Got a process that shouldn't be manual?

Describe what someone does by hand today. That's usually enough for us to tell you whether it's a small job or a real project.