Case study: GradNextSteps
This case study focuses on the product and engineering approach. Certain implementation details have been intentionally generalized for security and proprietary reasons.
AI can write code. Increasingly, it can design interfaces, reason about architectures, investigate bugs, generate tests and work across an existing codebase.
So what does the role of an engineer look like when AI can handle a large part of the implementation?
I have been exploring that question in practice while building GradNextSteps, where I serve as Co-founder & CTO.
The answer, at least from my experience so far, is not that engineering becomes unnecessary.
It changes.
The emphasis moves increasingly from manually producing code to understanding the product, designing the system, evaluating what AI produces and making sure the resulting system actually works.
This is the story of how we built GradNextSteps using that approach.
The Product Behind the Experiment
GradNextSteps is a Boston-based education technology company founded by six co-founders spanning business, marketing and technology.
The idea is straightforward but the problem is not.
Students make some of the most consequential decisions of their lives when choosing what to study, where to study and eventually what career direction to pursue.
Yet the guidance available to them is often fragmented.
Students may rely on education agents, family and friends, forums or individual advisors. Programme information such as fees, entry requirements and graduate outcomes is spread across university websites and frequently presented in inconsistent formats.
Most importantly, the process often starts with a course or university and only later asks whether it is actually suitable for the student.
GradNextSteps approaches the problem from the other direction.
Start with the student.
The platform uses structured assessments to understand aptitude, interests, working style and education preferences, and then combines that information with guidance, mentorship and programme intelligence.
The platform therefore needed to be much more than a public website.
It needed to manage a continuing relationship:
assessment → proposal → payment → advisor assignment → milestones → documents → follow-ups → mentorship
That meant building an actual product platform with multiple users, permissions, workflows, transactions and state over time.
What We Built
The platform has evolved into a multi-role digital product.
Students can complete the Aptitude Compass and Education Pathway Diagnostic, access a personal dashboard, submit intake information, receive proposals, make payments and engage with mentors.
The platform also includes University Match, which uses structured programme information and student profiles to support programme discovery. That capability has been built but is not yet publicly enabled.
Mentors have their own workflows for profiles, pricing, availability, requests and client management.
Advisors can manage leads and clients, create proposals, maintain private notes and track engagements through defined stages and milestones.
Administrators have an operational environment covering users, roles, pricing, content, notifications, communications and business metrics.
The platform also supports Stripe-based payments, including one-off transactions and instalment plans, together with automated transactional email and delivery tracking.
Behind that sits an education-data capability combining official US education data with automated extraction of information from university websites, creating structured information that can support programme discovery and recommendations.
My Role as Co-founder & CTO
GradNextSteps is very much a company, not a solo project.
The six co-founders bring different perspectives across business, marketing and technology. As ideas and potential new capabilities emerge, we discuss them collectively and consider them against the broader product and business objectives.
My responsibility is to take the technology and product decisions forward.
I lead the detailed product and engineering work, including:
product workflows
architecture
data-model decisions
implementation strategy
security considerations
technical integrations
testing and validation
production evolution
I also contribute directly to the product's visual design, including information hierarchy, interface structure, typography and overall visual direction.
I designed the GradNextSteps logo as part of that broader product and brand work.
The important distinction is that my role is not to manually type every line of code.
My role is to determine what needs to be built, how it should work, how the pieces fit together and whether the implementation is actually correct.
How We Developed It
The initial platform was built using Lovable and ChatGPT.
As the product became more sophisticated, the development workflow evolved.
Today, the primary tools are:
Claude Code for repository-level analysis, investigation, architecture discussions and detailed implementation instructions.
Lovable for implementing and committing the resulting application changes.
ChatGPT as an additional perspective to challenge proposed designs and approaches.
The process typically starts with a new requirement or feature.
I first define the user flow and the product behaviour.
Then I work through the architecture and any required data-model changes, often using Claude Code to inspect the current repository and reason about the changes in the context of the existing system.
Claude Code can work from the actual state of the repository rather than an abstract description of the application.
I review the proposed approach, refine it and determine what should actually be implemented.
The implementation then goes through Lovable.
Before release, I test the change in the preview environment, validate the business behaviour and review security implications before publishing it to production.
The resulting loop is roughly:
Business requirement
↓
Product workflow
↓
Architecture and data model
↓
AI-assisted implementation planning
↓
Human review
↓
Implementation
↓
Preview
↓
Testing and validation
↓
Production
The AI is deeply involved in implementation.
But the engineering process remains human-led.
AI-Assisted Development Requires More Than Prompting
One of the strongest lessons I have taken from this project is that AI-assisted development is broader than knowing how to write good prompts.
The person directing the build needs enough understanding of the overall system to evaluate what the AI is producing.
That understanding spans multiple areas.
Product
Requirements, user journeys, workflows, business rules and acceptance criteria.
Engineering
Architecture, database structures, APIs, integrations and application behaviour.
Technology and security
Cloud infrastructure, networking, DNS, authentication, authorisation, email systems, payments and security controls.
Design
User experience, information hierarchy, visual design, typography and usability.
These areas are interconnected.
A change that looks sensible from a coding perspective can affect the database.
A security recommendation can unintentionally interfere with a legitimate business workflow.
A change to authentication can alter the user journey.
A design or rendering decision can affect how public content is discovered by search engines and AI systems.
AI can move very quickly across all of these areas.
The person directing the build needs enough context to recognise when something is appropriate, when it is incomplete and when it is simply wrong.
That does not mean everyone needs the same background or level of expertise.
It means that the more of the system you can understand, the more effectively you can direct and evaluate AI-assisted development across that system.
My own experience across enterprise technology, infrastructure, cybersecurity, product development and design provided that broader context while building GradNextSteps.
AI then became an accelerator.
AI can accelerate implementation. Understanding still has to come from somewhere.
Where Cybersecurity Changes the Way I Use AI
Security is a particularly good example.
AI is useful at identifying potential vulnerabilities and suggesting security controls.
But I don't treat every security recommendation as something that should automatically be implemented.
A control can be technically sound and still break an intended feature when applied without understanding the surrounding workflow.
The process therefore becomes:
AI identifies or suggests → I verify → I assess the impact → I decide what should actually change
That principle applies to authentication, access control, data handling, payments and other sensitive areas of the application.
My cybersecurity background is valuable here not because AI cannot identify security issues, but because security decisions have to be considered in the context of the whole product.
Building for Production Changes the Equation
Another important aspect of the project is that the platform has not remained static.
The original GradNextSteps implementation has undergone a significant overhaul as the product and its requirements evolved.
One example was the rendering architecture for the public website.
The earlier implementation relied heavily on client-side rendering, which created limitations for search-engine and AI-agent discovery of public content.
The public pages were subsequently moved to server-side rendering to address that problem.
That change was not simply about generating some new code.
It required understanding the existing implementation, identifying why the problem existed, determining the architectural change required and then validating that the change did not create unintended consequences elsewhere.
This is another area where I have found AI highly capable as an implementation partner, but still dependent on someone understanding the system well enough to direct the change.
What AI Got Wrong
This is probably the most important part of the story.
AI is extremely good at producing output that looks correct.
That is different from producing output that is correct.
Plausible but nonexistent university URLs
An automated discovery process produced 22 university catalogue addresses.
17 of them did not actually exist.
The output looked plausible enough to be dangerous because nothing about the strings themselves obviously indicated that they were fabricated.
A confident but inappropriate source
AI once suggested that the Common Data Set was the only credible source for admission cut-offs.
A second AI review identified the problem. The relevant section was focused on undergraduate admissions and therefore did not address the postgraduate use case we needed.
The original answer was specific, convincing and wrong.
The business rule that looked fine
At one point an AI-generated workflow resulted in students receiving a link to the complete paid report.
That was not the intended product behaviour.
The report should only be released after enrolment.
The implementation was plausible.
The business logic was wrong.
Two correct decisions that broke production
Perhaps the best example involved a database function.
AI correctly implemented restrictive permissions.
It also correctly generated a random token.
Both pieces looked sound individually.
Together, they were incompatible and caused assessment submissions to fail in production.
That incident reinforced something I now consider fundamental to AI-assisted engineering:
A system is more than the sum of individually plausible pieces of code.
AI can produce the pieces.
Someone still has to understand how they interact.
By the Numbers
The development repository provides a useful picture of the scale reached during approximately six months of development:
~6 months
Development period
79
Screens/routes
~73,500
Lines of code
4
Major user roles
2,269
Repository commits
1
Technical founder leading engineering implementation
Live
Production status
The figures are not intended to suggest that more lines of code or more screens make a better product.
They demonstrate something else:
A very small technical function can now produce a surprisingly substantial amount of software when AI is integrated into the development workflow.
What This Has Changed for Me as an Engineer
The biggest lesson from GradNextSteps is not that AI can generate software quickly.
That part is increasingly obvious.
The more interesting change is where the engineering effort goes.
Less time can be spent manually producing routine implementation.
More time can be spent on:
understanding the problem
designing the product
modelling workflows
thinking through architecture
defining data structures
evaluating AI-generated implementation
testing interactions
reviewing security
understanding operational consequences
The bottleneck can therefore move from:
"How quickly can I write this?"
to:
"Do I understand what needs to be built, and can I determine whether what AI produced is actually right?"
That is the distinction I now associate with AI-assisted product engineering.
Built With AI, Not By AI
I don't see AI-assisted product development as "letting AI build the product."
I see it as a different engineering model.
The AI can generate implementation at a speed and scale that would have been difficult for one person to achieve previously.
But the human still needs to understand the business problem, design the system, establish the constraints, evaluate the output and take responsibility for the result.
In GradNextSteps, the product direction is shaped collaboratively by the founding team.
The technology and engineering implementation is led by me.
AI has become a significant part of how that implementation happens.
The result has changed how I think about software engineering.
AI is not replacing the engineer. It is changing what the engineer spends their time doing.
And perhaps the most important lesson is this:
The faster AI becomes at producing software, the more valuable it becomes to know whether that software is actually the right software to produce.
That, to me, is the essence of AI-Assisted Product Engineering.
About GradNextSteps
GradNextSteps is a Boston-based education technology company founded by six co-founders across business, marketing and technology. The platform combines structured assessment, education guidance, mentorship and programme intelligence to help students make more informed education and career decisions.
My role: Co-founder & CTO, leading product and technology.
Learn more about GradNextSteps