How We Work
From first conversation to launch and beyond - a straightforward, honest process with no surprises.
Every project is different, but the process we follow is consistent. It is designed around one principle: you should always know exactly what is happening, what is coming next, and what it will cost. No surprises, no scope creep that appears uninvited on an invoice, and no going quiet for six weeks while development happens in a black box.
What follows is an honest description of how a typical bespoke project runs from first contact to launch. Time-based engagements and fixed-price packages follow a lighter version of the same process - the principles are identical even if the formality differs.
The Project Journey
Initial Conversation
The first conversation is free and without obligation. We use it to understand your project at a high level - what you are trying to build, what problem it solves, what your timeline looks like, and roughly what budget you are working with. By the end of it, you will have an honest indication of whether your requirements and budget are aligned, and whether we are a good fit for each other. If we are not the right choice for your project, we will tell you that here rather than further into the process.
Discovery and Scoping
If the initial conversation identifies a good fit, we move into a structured discovery phase. This is where we invest real time in understanding your business - the workflows that matter, the data that flows through your systems, the users who will interact with what we build, and the constraints we need to design around. This phase produces a technical specification: a document that defines exactly what we are building, why we are building it that way, and what success looks like. The specification is the foundation of everything that follows. It is also the document that allows us to quote accurately - which is why we never provide a fixed-price estimate before this work is done.
Architecture and Technical Design
Before development begins, we design the system architecture - the database schema, the API structure, the authentication model, the integration points, and the infrastructure approach. These decisions are made deliberately and documented clearly. Architecture decisions made in this phase determine how much every subsequent decision costs - getting them right upfront is the most cost-effective investment in any software project. We explain the key architectural choices in plain language so you understand what we are building and why, even without a technical background.
Phased Development
Development is delivered in phases rather than as a single large release at the end of a long period. Each phase produces working software that you can see, test, and give feedback on. This means problems are identified early when they are cheap to fix rather than late when they are expensive. It also means you can adjust priorities between phases as your understanding of the product develops - a feature that seemed essential in scoping sometimes becomes less important once you see the core working, and new priorities emerge. We demo progress regularly so you always know exactly where the project stands.
Testing and Review
Testing is not a phase at the end of development - it happens throughout. Every feature is tested as it is built, and each phase ends with a structured review before the next one begins. Before launch, we conduct thorough testing across the full system - functional testing against the specification, performance testing under realistic load, security review, and cross-browser and cross-device testing where relevant. We do not launch software we are not confident in, and we do not consider testing complete until the system behaves correctly under the conditions it will face in production.
Launch and Deployment
Deployment is not an afterthought - it is engineered from the start. We set up CI/CD pipelines, staging environments, and production infrastructure as part of the project, so the deployment process is automated, tested, and reliable before launch day. The actual go-live is a planned, low-stress event rather than a manual process with fingers crossed. We monitor the system closely in the period immediately after launch and are available to respond quickly to anything that needs attention.
Ongoing Support and Evolution
Launch is the beginning of the most important phase, not the end of the project. We provide ongoing support, maintenance, and feature development after every engagement. Systems need security updates, dependency management, and compatibility fixes as the platforms they run on evolve. Products need new features as users provide feedback and business requirements change. We are available for all of this - either through an ongoing retainer or ad-hoc support as needed. The relationship does not end when the final invoice clears.
How We Work With You
A few things that are consistent across every engagement, regardless of the project type or size.
You work directly with the engineer
There are no account managers, no project managers, and no hand-offs between a sales team and a delivery team. You work with Owen throughout - the same person who scopes the project, designs the architecture, writes the code, and is available after launch. This means faster decisions, clearer communication, and full accountability in one place.
Nothing progresses without your agreement
Every significant decision - architectural choices, scope changes, technology selections - is explained and agreed before we proceed. You are never presented with a fait accompli and asked to accept it. If something needs to change, we have the conversation first.
We tell you when something is not the right approach
If a better solution exists - whether that is a different architecture, a scope reduction, or an off-the-shelf product that would serve you better than bespoke development - we say so. We would rather recommend the right answer than deliver the wrong one competently.
Scope changes are handled explicitly
Requirements evolve in every project. When they do, we assess the impact on timeline and cost, explain it clearly, and agree how to proceed before implementing anything. You never discover a cost impact on the invoice - it is discussed and agreed before the work begins.
Engineering Practices
The way we manage development is as important as the code we write. These practices are not optional extras - they are how we ensure that projects are delivered reliably and that what we build remains maintainable long after launch.
Version control and branching
All code is version-controlled using Git with a structured branching strategy. Every change is traceable, every release is tagged, and rollback to any previous state is straightforward. Code reviews are part of the process - every significant piece of work is reviewed before it is merged.
CI/CD pipelines
Continuous integration and deployment pipelines are set up for every project. Code is automatically built and tested on every commit. Deployments to staging and production are automated, consistent, and auditable. Manual deployment steps that introduce human error are eliminated.
Testing throughout
We write tests as part of development rather than as an afterthought. Unit tests cover critical business logic. Integration tests cover the connections between components. End-to-end tests cover the workflows that matter most to users. The test suite runs automatically on every build, so regressions are caught immediately rather than discovered in production.
Documentation as a deliverable
At the end of every engagement, you receive documentation covering the system architecture, the database schema, the deployment process, and the key decisions that were made and why. This documentation is a genuine deliverable - not a checkbox exercise. It is what allows you or any future developer to understand and maintain the system without needing to reverse-engineer it.
Security by default
Security is built into every layer of every system - not added at the end. Authentication is implemented correctly. Data is encrypted in transit and at rest. Input validation prevents injection attacks. Dependencies are kept current. Access controls are enforced at the application and database layer. We do not ship software that we know to have security problems.
What to Expect as a Client
Working with OLXR is different from working with an agency. Here is what that difference looks like in practice.
- You will receive regular written updates - typically weekly during active development phases
- You will see working software at the end of every development phase - not at the end of the project
- You will be asked to make decisions promptly - we cannot progress without your input on key questions
- You will be told honestly when something is taking longer than expected or when requirements are creating complexity
- You will receive a detailed estimate before any fixed-price work begins - never after
- You will own everything we build - source code, documentation, and all intellectual property
Frequently Asked Questions About Our Process
Ready to Get Started?
The first step is a conversation. Tell us about your project and we will give you an honest view of the process, the timeline, and whether we are the right fit.
Let's TalkFree consultation · No commitment · Response within 24 hours