Mendix and software development
Enterprise projects
Business systems built for large Korean companies, set out project by project with the role held on each.
Context and problem
- Most of the work is moving approval-chain processes into systems. Access control and exception handling are where the effort goes.
- What a user may see varies by grade and department; sensitive figures such as budget need selective disclosure on shared screens.
- With external integrations, a fault on one side stops the work on the other, so defensive implementation is required.
- Client names are published on the home page. Which entry belongs to which company is not, nor are dates, contract structure or system names.
Early work
Designed and built UI test automation with Python and Selenium, replacing repeated manual checks with regression tests.
I was the principal developer for the design and the build.
Built the administrator back office for a SaaS sales-information platform, where operators check and correct data directly.
I implemented the portion assigned to me.
Role, period, and scope
Project by project
Letters are arbitrary and unrelated to the order of the client list, to when the work happened, or to its size.
Client A
Employee awards and recognition system
Nomination through approval, scattered across steps, brought into one system. Built for several thousand concurrent users.
- Role
- Development lead · principal developer, Team work
- What I did
- Designed and built the approval workflow across nomination, review and sign-off
- Defined per-step states and permissions in one place; progress stays traceable when owners change
- Improved bulk spreadsheet export performance, starting with the query
- Addressed findings from a server security review
Client B
Health and safety management platform
Led one part of a site health-and-safety platform. External public data handling and role-based screen control were the main problems.
- Role
- Part lead developer, Team work
- What I did
- Implemented handling of unstable external public data defensively, preventing data errors from becoming outages
- Consolidated report screens into a shared widget so several screens use one format
- Designed the role-based permission structure for feature differentiation
- Ran sprint review presentations and client discussions
Client C
Budget management system
Departmental budget execution and tracking. Budget figures had to stay visible only to authorised users on a shared screen.
- Role
- Developer, Team work
- What I did
- Designed the permission-based access control for budget information
- Attached visibility and execution rights to roles rather than screens, centralising permission changes
Client D
Production engineering systems (several projects)
Several business systems for a production engineering division, combining heavily branched UI with live-update screens.
- Role
- Developer, Individual work
- What I did
- Designed heavily branched screens and improved them against end-user feedback
- Built WebSocket-based live communication with a purpose-made UI
- Handled faults from the Linux deployment environment and external database changes
Client E
Engineering data integration platform
Integration between an off-site engineering data system and a cloud application. Attribute mismatches and network routing recurred as faults.
- Role
- Developer, Individual work
- What I did
- Reimplemented the integration as a custom Java action, resolving attribute-name mismatch errors
- Traced cloud–on-premise communication faults through network logs to identify the cause
- Built the large-model visualisation viewer and single sign-on integration
PoC
Pre-adoption validation (several clients)
Technical validation requested before adoption decisions. Several grouped into one entry so none can be tied to a single client.
- Role
- Developer, Individual work
- What I did
- Designed integration with external systems of record and built data synchronisation
- Reshaped stock list screens to match the actual workflow
- Some validations went on to become funded projects
System map
Request flow
Recommendation → review → approval state transitions, with different actions valid at each step.
Permission layer
The layer where a role determines available features and readable data.
Reporting components
A reporting layer several screens reuse under the same rules.
Integration boundary
A boundary wrapping unstable integrations so failures do not reach the user.
Implementation evidence
Client screens are not published. The diagram sets out the structure these projects had in common.
Measurable outcomes
- Cut a large export that used to take minutes down to about ten seconds
- Work postponed because of the wait could be done immediately.
- Architecture sized for thousands of users
- Design baseline set so query and notification performance holds as users are added.
Reflection
- In enterprise systems, not breaking existing rules is harder than adding features. I document current behaviour before changing it.
- Separating team delivery from personal contribution was the part I was most careful about. Unverifiable results were left out.