Building a first version
You want to make the big decisions now, before more code is built on top of them.
Architecture Review
Find out what could hold your software back, before it gets expensive to fix.
We check how your software is built, point out what could go wrong, and help you decide what to fix first and what can wait.
WHO THIS IS FOR
Three times a review is worth it.
You may not need one. These are the moments when a second pair of eyes helps most.
Growing a product that already works
New customers and features are showing the limits of how it was built.
Getting ready for a big change
You are planning a big launch, a move to new systems, or a way to keep each customer's data separate.
WHAT WE REVIEW
What we look at.
It depends on your product and what we can access. We agree the exact list before we start.
| Area | What we check |
|---|---|
| The big picture | The main parts of your software, how they depend on each other, and why they were built that way |
| Customer data | Whether each customer's data is kept apart, where that matters |
| Who can do what | Roles and access rules, and whether they are checked everywhere |
| The behind-the-scenes part | The most important flows, the outside tools you connect to, and what happens when something fails |
| Speed | What is likely to slow down, based on the numbers we can get |
| How easy it is to change | Parts that are tangled together, risky dependencies, and what future changes will cost |
| Servers and cloud setup | How it is released, how you would spot problems, and what could cause an outage |
Every review is tailored to your product. We don't dig into every area every time.
WHAT YOU RECEIVE
Findings you can act on, in order of importance.
- A summary of what we reviewed
- A ranked list of findings, each with the reason behind it
- What each risk could cost you
- What we recommend you do next
- A call to talk it through
Fix nowIssues with real impact or likelihood today.
Plan nextWorth scheduling before they start to cost you.
Monitor for laterReal, but not urgent. We tell you what to watch.
A review is not a full code check, a hacking test, a stress test or a certificate, unless we agree to include one.
PROOF FROM REAL WORK
The kind of problems a review looks at.
Three products, three different problems. Each case study explains what we decided and why.
Gloup
Software for salon chains.
- Challenge
- Many salons needed their own separate data, but on one shared platform.
- Decision
- One platform for everyone, where each chain sees only its own data and roles control who can do what.
TopGrade
Online learning software used by several colleges.
- Challenge
- Each college's data had to stay separate, and exam days brought heavy traffic.
- Decision
- We split the data by college inside the database.
Hita
An online store with a growing catalogue.
- Challenge
- Product pages got slower as the catalogue and traffic grew.
- Decision
- We changed how product data is read and saved popular results so they load quickly.
HOW IT WORKS
Five steps. We agree the scope first.
We confirm timing and fees once we know what is being reviewed. We don't quote before we understand the job.
First conversation
We learn about your product, your worries and your goals.
Agree the scope
We agree what we will look at, what access we need, what you will get, and what is not included.
The review
We look at the agreed parts of your software and the evidence behind them.
Findings and advice
We explain the risks, the trade-offs and what to do first.
Next steps
You fix things yourself, or talk to us about helping.
WHO DOES THE WORK
You talk to the person doing the review.
Rajesh Ayyavu founded Tenlyr. He leads the first conversation and does the review. There is no sales handoff.
If you ask us to do the fixing afterwards, that is agreed separately. Tenlyr's engineers do the work, and Rajesh stays responsible for it.
QUESTIONS
What founders usually ask.
Is this right for a first version, or only for an existing product?
Both. For a first version, we focus on decisions that are costly to undo later. For an existing product, we focus on what is already under strain.
Do you need to see our code?
It depends on what we agree. Some reviews use a walkthrough, diagrams and documents. Others need read-only access to code, settings or numbers. We agree this before we start.
What is included, and what is not?
We cover the areas we agree together. We don't include a full code check, a hacking test, a stress test or a certificate unless we agree to add one.
Will you tell us to rewrite everything?
Only if the evidence says so. Most findings are targeted fixes. If a rewrite really is the honest answer, we will say so and explain the trade-offs.
Can we do the fixes ourselves?
Yes. We write the findings so your team can act on them without us. If you want our help, that is agreed separately.
How do you handle confidentiality?
Before we start, we agree what we can see and how it is shared. We are happy to sign an NDA.
What happens after the review?
We talk through the findings on a call. Then you decide: act on your own, or talk to us about more help.
REQUEST A REVIEW
Tell us about your product.
We only ask what we need to see whether a review makes sense. Rajesh reads every request himself.
Request received.
Rajesh will read what you sent and reply by email.