Web · App
Web & App Service
Peak load and data growth are sized at design time. Source code, deployment procedures and incident runbooks are handed over in full.
Overview
What we deliver, and how
Services break months after launch, not on launch day. Data piles up and list screens slow down; the server buckles on the day applications surge. By then the people who built it have usually moved on.
So peak load and query performance as data grows are settled at design time. What you see first is the screen mockup, but what gets decided behind it is this.
Requirements change mid-project. That is why we show you working screens every two weeks. Show it once at the end and there is no time to fix anything, so you accept it as-is.
You get all of the source code, handed over with deployment procedures and incident runbooks. Whether you continue with us is something you decide after that.
We have been building web and app services since 2018, across public sector clients such as Suncheon City, the Namwon Bio Industry Research Institute, the Gwangju Information & Culture Industry Promotion Agency and Chonnam National University's industry-academic foundation, alongside private work including Gwangju FC.
The problem
Where projects usually start
These situations recur in outsourced development. If any apply, we recommend talking to us before kickoff.
Check whether any of these apply to the project you are preparing.
- 01
Untouchable once delivered
Changing a single line means filing a request and missing the moment while you wait.
- 02
Users notice the outage first
By the time a phone call tells you, hours have passed — and finding the cause takes hours more.
- 03
Systems that do not talk
A new service that does not connect to the old one means entering the same data twice.
How it works
Size the load → Demo every two weeks → Operate against a baseline
Today
Even one line of copy needs a ticket
The moment passes while you wait for a reply
You hear about outages by phone
Hours after they started
Separate from the systems you already run
The same data typed in twice
02What we deliver
Size the peak load
Surge timing and data growth calculated at design time
A working demo every two weeks
Run on the assumption requirements will change
Learn the baseline
Normal patterns learned so departures stand out
03After delivery
Edit it yourself in the admin
Copy, images and notices without a deploy
Alerted at the first sign
Read against deploy history to narrow the cause
Source and documents handed over in full
Including deploy runbooks and incident procedures
- Zero-downtime deploys
- API integration
- Handover docs
We plan for month six, not launch day
Our approach
How GENIESOFT responds
One response to each of the three situations above.
- Before
- Screens that need a request
- After
- screens you edit yourself
Copy, images and notices are edited in an admin screen, so operations are not tied to a release schedule.
- Before
- Outages you hear about by phone
- After
- operations that tell you first
Deviations from the norm are caught and alerted automatically, and shown next to deploy history to narrow the cause.
- Before
- Entering everything twice
- After
- entering it once
We connect to what exists through APIs and design the new side around the data already there.
Project flow
How a project runs
The actual sequence a project moves through, step by step.
- 01
Design
We sit with real users, rework the sequence, and agree on wireframes. Aligning here avoids rework later.
- 02
Build and demo
Working screens every two weeks. Requirements almost always change, so we correct course as we go.
- 03
Operate and monitor
Deviations from normal surface early, so you act on signals instead of repairing after an outage.
Typical projects
Where this applies
The kinds of projects we are most often asked to take on in this field.
01
Customer-facing services
Screens the public uses directly — applications, lookups, payments. Peak load and query performance as data grows are handled at design time.
- Before
- Slows down under peak load
- After
- Designed to hold at peak
02
Internal tools and back office
Moving spreadsheet and paper work onto screens. Copying the existing flow verbatim often makes it worse, so we sit with actual users and rework the sequence first.
- Before
- Run on spreadsheets and paper
- After
- Handled and queried on one screen
03
Ops automation and anomaly detection
Adding monitoring and automated response to services already running. Deviations surface early, so you act on signals instead of repairing after an outage.
- Before
- Noticed only after an outage
- After
- Flagged as soon as signals appear
Work
What we built here
Projects GENIESOFT has delivered in this field.
FAQ
Common questions
Questions we often receive while clients are evaluating a project.
Can it integrate with our existing system?
Usually yes, but we need the other system’s API documentation and a contact. Without documentation, integration testing takes longer and we schedule for it.
How much maintenance is needed?
It varies with scale, but OS and browser updates and security patches keep coming, so "build once and leave it" does not hold for long. We hand over a list of recurring work.
Do we own the source code?
Per contract. By default the deliverables include full source code, handed over with deployment procedures and incident runbooks.
Principles
What is different
Problems clients commonly hit with outsourced development, and what we do about each.
| Common problem | Our approach | What changes |
|---|---|---|
| "Done" means different things to each side, and it surfaces at handover | Deliverables and acceptance criteria are agreed in writing before kickoff | Nothing left to argue about at acceptance |
| Progress is reported on paper; the real thing appears only at the end | We show working software every two weeks | A wrong turn is caught within two weeks |
| Once delivery is done, the vendor goes quiet | Deployment procedures and incident runbooks are handed over with the code | Operation continues even when staff change |
| Cross-domain work needs multiple vendors, and blame moves between them | XR, AI, web and app, and games sit in one organization | One contract, one party accountable |
Responsibilities
Who does what
What we do at each stage, and what you confirm. Most delays come from late confirmation, so we make both sides explicit before kickoff.
| Stage | GENIESOFT | Client | Deliverable |
|---|---|---|---|
| 01Scoping | Requirements analysis, feasibility review, scope and schedule estimation | Confirm priorities, share budget range | Proposal and quote |
| 02Design | Screen design, data modelling, prototypes for risky areas | Review and approve the design | Design document and prototype |
| 03Build | Two-week iterations, demo every other week, progress updates | Feedback on demos, hand over content and source material | Working build and source code |
| 04Acceptance | Acceptance testing support, defect fixes, staff training | Verify against acceptance criteria and sign off | Acceptance record and operations manual |
| 05Operate | Warranty support, incident response, maintenance | Assign an operations contact | Deployment procedures and incident runbooks |
Contact
Start your project
Requirements still taking shape? That's fine. An engineer reviews your inquiry and replies within two business days.
- No brief needed
- Scope and timeline reviewed first
- Reply within two business days
