We build software, then make it fast and hard to break.
AIQGM ships iOS, Android and web products. We also work on the ones already in production: security reviews, database performance, and the fixes that come out of both.
Two kinds of work
Building something new
A first release, a rebuild, or a second platform. We scope it in writing, ship in two-week cycles, and hand over a codebase your own team can keep running.
iOS development · Android development · Cross-platform · First release · Taking over an existing app · Store releases and upkeep
Web application development · API and backend · Front-end engineering · Legacy modernization · Internal tools · Maintenance
Fixing what’s already running
The app works, but it’s slow, expensive to host, or nobody has looked at it the way an attacker would. We measure first, fix in order of impact, and show you the numbers.
Web application penetration testing · Mobile application assessment · API security testing · Secure code review · Cloud configuration review · Hardening
Performance audit · Query and schema fixes · Index work · Connections and caching · Right-sizing · Upgrades and migrations · Backup and recovery check
What a finding looks like
Written for the engineer who has to fix it.
Every issue in a security or database report comes with how we found it, the specific change that fixes it, and how we’ll check. No links to a generic best-practices page. Here are two in the format we use.
Any signed-in user can read any invoice
- What we saw
GET /api/v1/invoices/10482returns the invoice. Changing the ID to10481returns another customer’s invoice, including billing address.- Fix
- Look the invoice up by
idand the session’saccount_id. Return 404, not 403, so IDs can’t be probed. - Retest
- Included once the fix is deployed.
Order history reads the whole orders table
- What we saw
WHERE customer_id = $1 ORDER BY created_at DESC LIMIT 20runs a sequential scan. The only index is oncreated_at. It’s the most frequent query on the account page.- Fix
CREATE INDEX CONCURRENTLY orders_customer_created_idx ON orders (customer_id, created_at DESC);- Measure
- p95 of this query on production traffic, same 24-hour window, before and after.
How an engagement runs
Four steps, each with something you can hold us to.
- Step 1
First meeting
Thirty minutes on Google Meet with an engineer, not a salesperson. You describe the problem; we ask the questions that decide the scope.
You get: an honest read on whether we're the right team
- Step 2
Written proposal
Scope, what's out of scope, timeline, team and price on a few pages. Nothing starts until you've agreed to it.
You get: a fixed scope and price, or a monthly rate for ongoing work
- Step 3
The work
In your repository and your tracker. A short written update every week, and a demo at the end of each cycle.
You get: a weekly update you can forward to your boss
- Step 4
Hand over
Code, documentation and credentials in your accounts, and a recorded walkthrough for whoever looks after it next.
You get: a system your team can run without us
Things we’ll tell you up front
If something off the shelf does the job, we'll say so.
Plenty of internal tools should be a spreadsheet and a form builder for another year. We'd rather lose the project than build you one you didn't need.
A pen test without a retest is half a pen test.
The report is where the work starts. Checking that the fixes actually closed the holes is part of the price, not an add-on.
Most slow databases need an index, not a bigger instance.
Upgrading the instance class is the easy recommendation. We measure first, and the answer is usually cheaper.
You own everything from the first commit.
Your repository, your cloud accounts, your store listings. If we stopped working together tomorrow, nothing would be stuck on our side.
Tell us what you're working on.
A few paragraphs is plenty. We'll read it, reply by email, and if it looks like a fit, set up a 30-minute Google Meet with an engineer.