Architecture and the first build
Laid down the application, authentication, and database on day one (first commit October 8, 2025) and owned the architecture through launch. Every later decision had a shape to fit into.
Case study · Consumer app · Olympia, WA · September 2025 to October 2026
Two people · First commit to store approval · A contractual launch date
I started it, lost a contributor mid-build, and still shipped on the day I said I would.
Mine'sCuter is a pet photo competition platform. I took it from a blank repository to a live web platform, native iOS and Android apps, and in-app purchasing built for both stores, and delivered it on the date written into the contract. Architected and led by Mink Solutions, engineered with one partner.
Apply to work with Mink Solutions- 2
- People on the team, start to finish
- Jul 31
- Web platform live, on the contract date
- 61,467
- Lines of production code
- 6
- Store submissions, no repeated mistakes
At a glance
01 · Summary What was built, and by whom
- Client
- Mine'sCuter LLC, a consumer pet photo competition platform with two founders.
- Timeline
- Engagement start September 2025. First commit October 8, 2025. Live July 31, 2026. Google Play approved September 29, 2026. Apple in final review.
- Team
- Mink Solutions: architecture, engineering, verification, store submissions, client leadership. Araptus (Kris Black): engineering partner from week one.
- Delivered
- Web platform, iOS app, Android app, weekly competitions, voting and rankings, Premium subscriptions, vote and boost purchases on three payment systems, push notifications, transactional email, contest rules and store compliance.
The situation
02 · Context The hard version of a software project
Most case studies describe a clean build with a stable team. This one had a clean start, and then the thing that actually happens to most projects: a key contributor left in the middle, and the date in the contract did not move.
| What I was working with | What it meant |
|---|---|
| Architected and started by Mink Solutions | The application, authentication, and database were laid down from the first commit. The architecture was mine to defend, not to guess at. |
| A contributor shipped 42% of all commits in seven weeks, then left | From February to late March 2026 one developer landed 384 commits and moved on. Intent for a large share of the product had to be reconstructed from the code, not asked for. |
| 355 source files, 113 API endpoints, 55 database migrations | Large enough that nobody held it all in their head. Undocumented behavior was the default. |
| A firm launch date in a signed agreement: July 31, 2026 | No option to extend. Scope had to bend instead. |
| A live alpha user base already on the platform | Every fix had to ship without breaking people already using it. |
The question was never "can two people build this." It was "can two people understand everything that exists, find what is quietly broken in it, and still hit the date."
Commits merged per month, from the project repository. 1,138 total.
| Month | Commits |
|---|---|
| Oct 25 | 25 |
| Nov 25 | 11 |
| Dec 25 | 34 |
| Jan 26 | 0 |
| Feb 26 | 232 |
| Mar 26 | 292 |
| Apr 26 | 159 |
| May 26 | 42 |
| Jun 26 | 36 |
| Jul 26 | 112 |
| Aug 26 | 72 |
| Sep 26 | 123 |
The February and March spike is the departed contributor. April onward is the two-person team carrying the project through alpha, security hardening, launch, and six store submissions.
What Mink Solutions did
03 · Scope Nine things one firm covered
A buyer usually hires three vendors for this list: an architect, a development shop, and someone to deal with Apple and Google. On this project all of it sat with one firm, with a single engineering partner brought in on day five.
Hands-on engineering
Shipped production code across the life of the project, from the initial platform to launch fixes to the copy and compliance changes that got the Android app approved. Not a manager who stopped coding.
Specification and verification
Audited every claim against the live code before it became a task, then wrote specs precise enough to implement without a conversation: exact files, exact lines, exact acceptance criteria.
Production monitoring and incident response
Caught a four-day silent sign-in outage and a 1,896-error-a-day launch-eve failure by reading the dashboards, not by waiting for a user to complain. Both fixed the same evening.
Security program ownership
Drove a full source-code security audit, closed every critical and high finding including two cross-user data exposures, and turned the fixes into automated tests that fail the build on regression.
App store strategy and submissions
Ran six store submissions end to end: listings, screenshots, demo accounts, age-rating questionnaires, data-safety declarations, written replies to every rejection, and a live appointment with Apple's App Review team.
Payments and compliance
Web, Apple, and Google purchasing with server-side validation and cross-platform reconciliation, plus the contest rules, age ratings, and prize structure changes the stores required. Built inside the retainer.
Client leadership and reporting
Owned the contract and the relationship. Daily updates while anything was in review, written status reports with every date and dollar, and the hard conversations delivered with the fix attached.
Partner delivery
Brought in Araptus (Kris Black) as the engineering partner from the first week and ran the two-person operating model: one person decides what is true, the other decides how it gets built.
The timeline
04 · Record Thirteen months, in order
| When | Event | Detail |
|---|---|---|
| Sep 2025 | Engagement begins | Phase 1 agreement signed September 18. Architecture and plan set. |
| Oct 2025 | First commit | Application, authentication, and database laid down by Mink Solutions on October 8. Araptus joins the project five days later. |
| Feb to Mar 2026 | The burst | A third contributor lands 384 commits in seven weeks, then leaves. 42% of the history now belongs to someone who cannot be asked. |
| May 2026 | Silent outage caught | Four-day sign-in failure found by reading error rates, fixed the same evening. Database upgraded after a 504 incident. Full security audit completed June 1. |
| Jun 28, 2026 | Launch agreement | Fixed scope, fixed date: July 31. Twelve launch items. Monthly support from August 1. |
| Jul 31, 2026 | Live on the date | Web platform live. All twelve items delivered. 1,896 errors a day found and fixed the night before. Apple and Google submissions sent at 11:11 PM. |
| Aug 2026 | Store rejections, both fixed | Google: an icon mismatch, my miss, fixed in a day. Apple: four items, the biggest being in-app purchase policy. Built the full purchase system for both stores inside the retainer. |
| Sep 2026 | Resubmissions | Apple submissions 2 and 3. Google submission 2 with in-app purchasing. Content-rating rejection fixed by changing the product. Google Play approved September 29. |
| Sep 29, 2026 | Live call with Apple | App Review confirmed every earlier issue is resolved and identified an App Store Connect bug on their side. Escalated through Developer Support. Apple approval is the last open item. |
What actually happened
05 · Incidents Four failures, and the rule each one produced
Any team can describe a project that went well. What tells you how a team will behave on your project is what they do when something breaks. These are real, from this engagement, with the dated readings behind them.
Incident 01 · Silent for four days
A database change shipped ahead of the code that depended on it
A security migration was applied to the live database while the code that accounted for it sat on an unmerged branch. Sign-in broke for every user. Nothing alerted, because the failure returned empty data rather than an error.
- Detected by
- Reading the database error rate during a routine review, not a user report
- Signal
- Error volume above 1,200 a day; platform success rate 56.6%
- Duration
- Four days
- Resolution
- The same evening it was found
Rule adopted Database migrations and the code that depends on them deploy together, in the same push, or the migration waits. No exceptions.
Incident 02 · Found the night before launch
1,896 database errors a day, on the eve of going live
A follow-on effect of the same migration. Thirteen code paths were still reading a table whose permissions had been tightened. Roughly 96% of database traffic was failing, and because the failures returned no error to the interface, the product looked like it worked.
- Detected by
- Monitoring the error rate on launch eve rather than assuming it was fine
- Scope
- A first sweep found 13 call sites; a second pass found 13 more, including one in code that runs on every request
- Result
- Success rate 77.2% to 100%, measured one hour after deploy
- Side effect
- Database request volume fell roughly 99%; the failing queries had been retrying
Rule adopted An automated test now fails the build if any of these paths regress. The fix is enforced by machine, not memory.
Incident 03 · Caught before it cost anything
A store policy violation that would have failed app review
A pre-submission audit found in-app purchases routed through a payment provider both app stores prohibit for digital goods: an automatic rejection, and one of the most common reasons first submissions fail.
- Detected by
- Auditing the mobile build against store policy before submitting
- Cost avoided
- A rejection cycle on a technicality, the night of a public launch date
- Additional
- Four further blockers found in the same audit: missing permission declarations that would have crashed the app on first photo upload
Rule adopted Platform-policy audit is a required gate before any store submission, not a step inside it.
Incident 04 · Rooted in the business model, not the code
Google's content rating flagged the prize structure
Google Play reads paid votes toward cash-value prizes as cash-convertible rewards, which forces an adults-only rating and a rejection. The code was fine. The product design was the problem, and the honest fix was to change the product, not the questionnaire answers.
- Detected by
- Google Play rejection, September 26, 2026
- Root cause
- Gift-card prizes plus purchasable votes. A policy interaction, not a defect.
- Resolution
- Prizes changed to shipped physical products; rules, listing, screenshots, and website updated to match. Resubmitted September 29. Approved the same day.
Rule adopted Store questionnaires are answered from the product as shipped. If the honest answer produces the wrong rating, the product changes first. I do not soften answers.
The pattern worth noticing: in all four cases nothing crashed and no user complained. Each was found because somebody was looking, or was handled the moment a platform raised it, and each produced a rule so the next person cannot repeat it.
Measured, not claimed
06 · Readings The platform on launch day, and after
Every figure below is a dated reading from a production monitoring dashboard or the repository, taken before and after a specific change.
Production monitoring, the week of launch, July 2026.
| Reading | Errors |
|---|---|
| 4 days before | 1247 |
| 3 days before | 1310 |
| 2 days before | 1420 |
| Launch eve | 1896 |
| After fix | 0 |
| Launch morning | 0 |
Before and after
Four readings that changed because of specific work.
| Reading | Before | After |
|---|---|---|
| Competition page weight | 25 MB | 0.9 MB |
| Idle real-time load on the database | 67.7% | 0% |
| Automated tests | 352 | 560+ |
| Success rate, launch week | 77.2% | 100% |
What was rebuilt underneath
| Area | What changed |
|---|---|
| Database access | Every data path audited and corrected; permissions rebuilt across the schema; an automated test suite that fails the build if the protections regress. |
| Real-time infrastructure | Measurement showed the existing approach consuming 67.7% of total database capacity while delivering nothing: the subscription list was empty. Removed and replaced with a simpler mechanism. |
| Security | Full source-code audit. Every critical and high finding closed, including two exploits that exposed other users' data. Signup-alias abuse closed. Session replay restricted to errors only, with no personal data. |
| Abuse protection | Challenge-based filtering at the network edge, per-endpoint rate limiting on every sensitive action, a daily vote cap that fails closed, and a rule so one store account cannot unlock multiple platform accounts. |
| Performance | Duplicate work removed from the request path, caching where data is near-static, queries consolidated on the busiest routes, and image delivery through an optimizer: competition pages from roughly 25 MB to under 1 MB. |
| Payments | Web, Apple, and Google purchasing behind a single entry point that dispatches per platform, with every web payment surface unreachable inside the native apps, enforced by an automated security test. |
None of this is visible to a user. It is the difference between a platform that grows and one that falls over at five thousand people, and it is the most expensive thing to retrofit after the fact.
Store review, honestly
07 · Submissions Two stores, six submissions, no repeated mistakes
First apps on new developer accounts draw the longest review queues, and every resubmission goes back to the end of the line. Most of the calendar below is queue time, not fix time. What matters is that no rejection ever repeated an earlier issue, and the biggest one became a feature.
| Date | Event | What I did |
|---|---|---|
| Jul 31 | Web live on the contract date. Apple and Google submissions sent the same night. | All twelve contracted launch items delivered. |
| Aug 6 | Google rejection: installed icon did not match the listing. | My miss. Android icons regenerated, version bumped, verified from the built bundle. Five stray advertising-ID permissions found and removed in the same pass. |
| Aug 11 | Apple rejection 1: in-app purchase policy, contest rules, iPad sign-in, age-rating questionnaire. | Built the full in-app purchase system for both stores. Published Official Contest Rules. Fixed the iPad sign-in anchor. Re-verified the rating on Apple's new questionnaire. |
| Sep 3 | Apple submission 2, with ten purchase products. | Written reply to every rejection point, fresh device screenshots, reviewer demo account. |
| Sep 8 | Apple rejection 2: two iPad edge cases. | Both fixed and deployed the next day, web-side, so installed apps picked them up with no new binary. Twenty behavioral tests added. Retested on a physical iPad Pro. |
| Sep 14 and 25 | Apple submission 3. Google submission 2 with in-app purchasing. | Live test purchase on the Android build verified server-side before submitting. |
| Sep 26 to 29 | Google content-rating rejection (Incident 04). Fixed, resubmitted, approved September 29. | Release held for a coordinated launch across both stores. Google publishes nothing until the client says so. |
| Sep 29 | Live App Review appointment with Apple. | Apple confirmed every prior rejection point is resolved and that the remaining purchase-item errors are an App Store Connect bug on their side. Escalated through Developer Support when the fix stalled. |
The rejection that became a feature
Apple's first rejection made in-app purchasing a condition of being in the store at all. The July plan had scoped that as separate Phase 2 work. Instead it was built inside the monthly retainer: Premium subscriptions and seven consumable products on each store, server-side receipt validation, reconciliation with existing web subscribers so nobody is ever double-charged, and a two-phase claim so a failed grant can never be reported as a successful purchase. Roughly 3,900 lines across 18 source files and more than 125 hours across two people, at no additional charge.
Under the hood
08 · Architecture One application layer, three storefronts, one set of rules
For the technical reader. The platform is a single codebase on one application layer, deployed serverless, with a relational database protected by row-level security, three payment systems reconciled server-side, edge protection against bots and abuse, authenticated transactional email, scheduled jobs for the competition lifecycle, and error monitoring with privacy-restricted session replay. The native apps are wrappers around the same application layer, so a web-side fix reaches installed apps without a new binary.
- Clients Web app (browser and PWA) · iOS app (App Store) · Android app (Google Play)
- Edge protection Bot challenge · rate limits
- One application layer 113 API endpoints · one purchase entry point that dispatches per platform · 560+ automated tests
- Database Row-level security · 55 migrations
- Payments Web, Apple, Google · reconciled server-side
- Email and push Authenticated sending · scheduled jobs
- Monitoring Error rates · replay with no personal data
The economics
09 · Structure What two people cost versus what a team costs
The comparison that matters is not hourly rate. It is how much of the budget goes into coordination rather than work, and how many people stand between you and the person writing the code.
| Measure | This engagement | Typical agency structure |
|---|---|---|
| People involved | 2 | A team, with an account layer on top |
| Layers between you and the person writing code | 0 | Account manager, project manager, tech lead |
| Time from decision to deployed | Same day, routinely | Next sprint |
| In-app purchasing on two stores | Built inside the retainer, no additional charge | A separate statement of work |
| Architecture, build, and store submissions | One firm, one point of contact | Often three vendors |
Where the savings actually come from
Not from cutting corners, and not from working cheap. From eliminating the coordination tax. There is no status meeting to translate a decision into a ticket, no handoff between the person who understands the business and the person who writes the code, and no billable hours spent explaining the project to someone new. In one overnight session a launch blocker was found, specified, implemented, reviewed, deployed, and verified in production. Apple's second rejection was fixed and live the next day. In an agency structure each of those is a two-week cycle.
How I work
10 · Method Made deliberately easy on your side
You always know where things stand
Every task is a written ticket with acceptance criteria you can read. Progress is visible in the tracker, not summarized in a meeting. Daily updates while anything is in review. When something is behind, you hear it from me first.
You are told the truth
Bad news comes with the fix and the timeline attached. When I am wrong, I correct it in writing where the mistake was made. When a platform is wrong, I get a live human on the record rather than resubmitting blind.
You are never locked in
Architecture decisions and known pitfalls documented in the repository. Automated tests so the next team inherits guardrails, not folklore. Everything written for whoever comes next, whether or not it is me.
You keep your own accounts
Platform, payment, and infrastructure accounts stay in your name. I am added as a collaborator and can be removed in one click. Fee-reduction programs enrolled on your behalf before revenue starts.
Questions buyers ask
11 · Questions Frequently asked
- Can a two-person team really take a consumer app from zero to both app stores?
- Yes, when the two people split the work along one clean line and verify everything against the code before promising it. This project went from a blank repository in October 2025 to a live web platform on July 31, 2026, with native iOS and Android apps and in-app purchasing built for both stores. Six store submissions, four of them rejections, none repeated an earlier issue. Google Play approved September 29; Apple is in final review.
- How long does App Store and Google Play approval take for a first app?
- First apps on new developer accounts draw the longest queues. On this project Apple's first review took eleven days to come back, and each resubmission went back to the end of the line. Google approved the content-rating fix the same day it was resubmitted. Most of the calendar is queue time, not fix time, which is why every submission has to be right the first time it can be.
- What happens when a developer leaves in the middle of a build?
- On this project a contributor left with 42% of the commit history. Because the architecture was laid down by Mink Solutions and every task was specified against the live code, the work continued without a reset. The hard part is understanding what exists, not rewriting it.
- Does a small firm cost less than an agency?
- Usually, and not because the work is cheaper. An agency bills for the people between you and the code. Here there are none, so a decision becomes a deployed fix the same day, and the in-app purchase system that would normally be a separate statement of work was built inside the monthly retainer. Your Scorecard shows what that looks like against your own numbers.
About Mink Solutions
12 · Who Spacecraft engineer, then small business.
Mink Solutions builds and fixes the systems businesses run on, from Olympia, Washington. It is run by Paul Minkler. Before this: about three years in aerospace at Lockheed Martin and Sierra Nevada Corporation, nine spacecraft, and a NASA award for commanding them through ground stations on three continents. Since 2017, nine years building and fixing the systems businesses run on: web and mobile apps, secure systems, payments, email programs, and the engineering rigor that makes them hold up.
Engineering partner on this project: Araptus (Kris Black), on the project from its first week.
What you get
The Security Audit
Every finding ranked, every critical and high fixed, tests that fail the build if they return
Built from Custom Builds and Audits
$2,500
ApplyZero to the Stores
Platform or app shipped to both stores on the date in the contract
Built from Custom Builds and Audits
from $25,000 · from $1,500 a month support
ApplyPlus applicable WA sales tax. Every price is a starting point; the Scorecard sets the number.
Have a project that stalled halfway?That is the version I am best at.A build that lost momentum, a date that cannot move, and a need to know what is actually true before anyone promises anything. Four openings a month. Apply, and the first thing you get back is a Scorecard with your numbers in it.
ApplyApply by 2 PM Pacific and you'll hear from me today. After that, by end of day the next business day.
paul@minksolutionsllc.comFigures are from version-control history, project tracker records, signed agreements, and dated production monitoring readings. Published October 8, 2026.
Mink Solutions LLC, Olympia, WA · Araptus, engineering partner.