DESIGN AND DEVELOPMENT / iOS & ANDROID
I design and develop iOS and Android applications that connect a considered interface with your business workflows. From discovery and prototyping through backend and integrations to testing and release preparation.
Work directly with Jakub Marcinkowski. Scope and delivery approach are agreed before the start.
Original product recording in a presentation frame. Playback starts only when you choose.
01 / ENGAGEMENT SCOPE
Scope follows the product’s needs, not a fixed feature list. We can build a new app, develop an existing product or start with discovery and a prototype.
Product design
We start with users and their essential tasks. I design screen structure, a prototype and a coherent interface, with attention to readability, error states and comfortable touch interactions.
Application and data
An app can use an existing API or a new backend. We define data, roles and integrations. If your team works without connectivity, we plan local storage and synchronisation rules.
Release preparation
We check agreed journeys on target devices and prepare the release materials. Publishing, handover and ongoing support are scoped before development begins.
02 / SELECTED WORK
Selected projects show different types of engagement: developing an existing product and collaborating in an engineering team. Each includes the scope delivered, responsibilities and deployment status.
REMONT PRO / WEB + iOS
I took over an existing project and developed it into a product available on the web and iOS. My work covered databases, payments, system improvements, testing and deployment.
FLEX / TEAM PROJECT
A working MVP with web, Android and iOS applications, maps and QR codes, connected through a shared API.
Built in a team of five. My contribution: frontend, backend, mobile applications, integrations and testing.
More SKICODE projects ↗03 / CONTINUITY
When a workflow needs offline access, we design local storage, retries and synchronisation rules. This example distinguishes a local entry from confirmed delivery.
Add an entry to explore the data flow.
Add entries and confirm their synchronisation. You can also interrupt the connection during transfer.
04 / DECISIONS BEFORE DEVELOPMENT
Platforms, device features, budget and future development determine the approach. We compare the options before committing to a build.
It may be enough for forms and portals. Offline, push and device integration capabilities need checking on the target platforms.
Some implementation can be shared. Tests, permissions and publishing still need to cover both platforms.
A close fit to each platform can require separate implementations. The choice follows required features, not a technology name.
DETAILS WE AGREE ON
Data first enters a local queue, with retries, interruption handling and clear sync status. Shared editing also needs conflict rules. An offline label alone does not solve these issues.
We agree image sizes, document formats, limits and storage. The app should explain why it asks for camera or location access. File access must depend on user permissions, not simply knowing a URL.
Core scenarios are tested on target devices before release preparation. Store accounts, descriptions, privacy information and assets need to be ready. Store approval belongs to the platform operator, so a fixed approval date cannot be promised.
05 / DELIVERY AND BUDGET
We agree first-release features, responsibility for assets and accounts, and acceptance criteria. Further stages can be scoped and quoted separately.
We define who uses the app, in what context and what they need to achieve.
We validate the critical journey before full development.
I build the mobile experience, backend and required integrations.
We test devices, resolve issues and prepare the release.
Platforms, device capabilities and data handling determine the scope. App development is separate from backend, developer accounts and maintenance. Offline synchronisation is a core part of the build, not a small optional switch.
Before work begins, you receive the agreed scope and collaboration terms. Release also depends on required materials and store operators’ decisions.
Prepare a pricing brief ↗BEFORE WE BEGIN
The choice depends on the audience and budget. During discovery I compare native and cross-platform approaches.
Yes, but offline operation affects data architecture and synchronisation, so it needs to be designed from the beginning.
I can prepare and guide the technical release. The developer accounts remain under the client’s ownership.
Often yes. A form, offer or simple portal may be better served by responsive web. An app makes sense when its capabilities justify the additional scope.
We can scope that integration after checking access and API capabilities. File ownership, folders, limits, permissions and upload failure handling all matter.
If agreed in the scope. A web panel, backend and mobile app connect, but each requires design and testing.
We design a queue and retries without duplicate entries. Users should see what is local, pending and confirmed by the server.
Your starting point
Choose what matters. Build a short brief for the contact form or save it for yourself. Nothing is sent automatically.
Android and iOS mobile app development Starting point: New project Goal: To be defined Key areas: To be agreed Scoping questions: - Who uses the app and on which devices? - Are photographs, QR or location needed? - What must work without internet? - Is there an existing backend or web panel?
Your text stays in this browser tab.
LET’S DISCUSS YOUR APPLICATION
Describe the users, the key feature and your current stage. You can also use the brief prepared above. I will follow up with questions and a practical next step.