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.
Scope of work
- Responsive web, iOS, and Android
- Admin systems and back office
- API design and legacy integration
- Cloud infrastructure and zero-downtime deploys
- AI-assisted anomaly detection and ops automation
Deliverables
- Requirements definition and screen designs
- Frontend and backend source code
- API specification
- Infrastructure diagram and deployment procedures
- Incident runbooks and staff handover
Technology
- React
- Next.js
- Node.js
- Flutter
- PostgreSQL
- AWS
The problem
Where projects usually start
These situations recur in outsourced development. If any apply, we recommend talking to us before kickoff.
- 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
- 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 |
|---|---|---|
| Acceptance criteria need to be agreed before kickoff | Deliverables and acceptance criteria are agreed in writing before kickoff | Acceptance is checked against the agreed criteria |
| Working software and progress need regular review | We show working software every two weeks | Demo feedback informs the next development steps |
| The operations team needs reference documentation | Deployment procedures and incident runbooks are handed over with the code | Operating procedures are documented for reference |
| Some projects require several technical disciplines | XR, AI, web and app, and games sit in one organization | Schedules and integration scope are coordinated across disciplines |
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 |
- [email protected]
- PHONE
- 0507-1301-7163