PRODUCT DESIGN / WEB DEVELOPMENT
I design and develop web applications, customer portals and SaaS products. A considered interface connects with business logic, data and integrations, from discovery and a focused first release through further development.
Work directly with Jakub Marcinkowski, from discovery to launch or the development of an existing product.
Original product recordings. Playback starts when you choose. My contribution is described below. Open recording ↗
Start with the workflowRoles, data and the outcome users need.
Define a focused scopeOne complete journey, not an arbitrary feature list.
Deliver a working productTesting, handover and a considered roadmap.
01 / WHERE AN APP ADDS VALUE
Not every problem needs a large system. We can improve a single workflow, give clients access to a service or prepare the first release of a new product.
We move inputs, calculations and dashboards into a controlled system. Results are compared with reference examples from the workbook rather than only copying its appearance.
↗Users see their own work, administrators manage access and history records meaningful changes. Roles and data visibility are defined before development.
↗We focus on one core problem, customer journey and delivery model. Billing and extra modules enter the first scope only when essential.
↗02 / EXPLORE THE WORKFLOW
A good application is more than an attractive dashboard. It defines who can make changes, who approves them and what the client sees. Explore the same workflow through different roles.
REQUEST WORKFLOW
Add a request or select a draft and send it for approval.
Sample data. Changes are not sent to any system.
In-memory demonstration, without authentication, a database or server storage. Reloading clears changes. A production application must enforce permissions on the server; hiding buttons does not protect data.
03 / REAL PRODUCTS
An independent product, an existing project taken forward and team collaboration. Each has a different context, so I distinguish product capabilities from my own contribution.
EDU-HUB / INDEPENDENT PRODUCT
My independent educational product: courses, coding exercises, learning progress and creator tools. I combine product decisions, interface design and platform development.
Jakub Marcinkowski / platform and Java Backend Developer course author. The product and its materials evolve in stages.
REMONT PRO / EXISTING PRODUCT DEVELOPMENT
I took over the existing RemontPro project and developed it into a product available on the web and iOS. My work included databases, payments, system improvements and testing. The Android version is currently being tested.
FLEX / TEAM ENGINEERING 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.
04 / BELOW THE SURFACE
What you see in the browser is part of a larger system. Data, roles and integrations are designed alongside the interface, not left until a problem appears.
Each role has its own tasks and views.
The server verifies who can perform each action.
A coherent model and defined access rules.
Scope depends on API availability and provider terms.
Illustrative structure. Architecture and integrations follow the project’s requirements.
I design journeys that lead to an outcome, including forms, empty states, errors, search and comfortable access from a phone.
Data, access and workflow logic need a coherent design. We define roles, validation, integrations and how to handle failures and retries.
We agree acceptance criteria and test critical scenarios before release. Documentation, account handover and support are defined in the scope.
DECISIONS WE DEFINE BEFORE DEVELOPMENT
Define the input, result and exceptions for one user journey. Later features belong on a separate roadmap so scope and price do not change with every new idea.
Hiding a button is not security. The server must verify access to data. We define roles, authentication, critical operations, backups and environments according to the information the application holds.
External services can become unavailable or return incomplete results. Validation, duplicate prevention and an event trail are part of data exchange. API availability and provider terms are checked before committing to an integration.
05 / HOW WE WORK
A new system does not need every possible feature at launch. We choose the starting point, define the outcome and agree what belongs on the roadmap.
A workflow description, screen map and priorities help validate direction before committing to a full build.
We build a complete path from input to outcome. Smaller scope does not remove the need for access controls, backups and tests.
I review the code, environment and constraints first. Integrations and migration are planned around current operations.
We map the workflow, user roles, data and the largest risks.
We select the smallest version that can deliver value and be tested.
Working parts of the product are delivered and reviewed regularly.
After launch, we analyse usage and plan the next improvements.
BUDGET AND RESPONSIBILITIES
A defined workflow and first release can be priced reliably. Larger systems may start with a separate discovery stage. Hosting, database, messaging and maintenance have their own usage-dependent costs.
Before work begins, you receive the scope, schedule and acceptance terms. New features, data migration and ongoing support are priced according to their agreed scope, not treated as undefined extras.
Prepare a pricing brief ↗BEFORE WE START
I first price discovery or a well-defined MVP. A fixed price for a large system without a specification would be guesswork.
Yes, when that software provides an API or another secure data-exchange method.
Yes. Maintenance, monitoring and further development can be a separate, clearly defined engagement.
Yes, after reviewing the workbook and its dependencies. Macros, imports and edge cases are scoped too, and results are compared with reference examples.
Code rights are defined in the agreement. Your company can own production accounts, infrastructure and data. Third-party libraries retain their respective licence terms.
Yes, but data isolation, roles and billing need to be designed into the architecture. This differs from an internal tool for one company.
Yes. We define one complete user journey and a separate list of later features. Subsequent stages can be scoped after testing the first release.
Your starting point
Choose what matters. Build a short brief for the contact form or save it for yourself. Nothing is sent automatically.
Custom web applications and SaaS development Starting point: New project Goal: To be defined Key areas: To be agreed Scoping questions: - Who uses it and how many users are there? - What happens manually or in Excel today? - What data and access rules are needed? - What must work in the first release?
Your text stays in this browser tab.
YOUR NEXT STEP
Tell me who will use the application, what makes the work difficult today and what the first version needs to do. You can use the brief above. I will follow up with questions and a practical next step.