Development Journal
"At some point the journal ceased to be a record of the development process and became one of its outputs."
Introduction
Exchange Opinions began as an attempt to answer a simple question:
How can public opinion be captured, aggregated and represented in a structured way without descending into the noise often associated with social media?
The platform combines elements of polling, dashboards, reporting, public participation and data visualisation to create a continuously evolving picture of opinion, understanding and interest across topics, services and locations.
This development blog records the major milestones and decisions made during development.
Entry 1 - Naming the Platform
Feature
Creation of the Exchange Opinions identity.
Decision
The name needed to describe both the purpose of the platform and the interaction taking place between participants. There were a few other suggestions mooted, some available, some not, however this one seemed more concrete and less abstract than some of those others.
Opinions are not merely collected.
They are exchanged.
Participants contribute views, consume insights and influence future discussions.
Philosophy
The platform is designed around participation rather than broadcasting.
Entry 2 - Branding and Visual Identity
Feature
Creation of logos, colours and branding.
Decision
The visual identity needed to appear:
- neutral
- trustworthy
- modern
- informative
rather than politically aligned or commercially aggressive.
Philosophy
The platform should present itself as an information service rather than an advocacy platform.
Entry 3 - User Authentication
Feature
User registration and login.
Technology
React front end
AWS Lambda
API Gateway
JWT authentication
Decision
Opinion submissions must be attributable to authenticated users while preserving privacy.
Philosophy
Trust begins with accountability.
Entry 4 - Topic Hierarchy
Feature
Structured topic categorisation.
Decision
Topics are grouped into logical categories to improve discoverability and reporting.
Philosophy
Information becomes more useful when it can be organised and compared consistently.
Early Concepts
Entry 5 - Geographic Hierarchy
Feature
Regional, Area and Local structures.
Decision
Users can submit opinions against multiple geographic levels.
Philosophy
National issues often have local impacts.
Local issues can reveal national patterns.
Entry 6 - Sentiment Framework
Feature
Introduction of structured sentiment categories.
Examples include:
- Concerned
- Interested
- Frustrated
- Confident
- Amazed
- Informed
- Uninformed
- Decision
Traditional positive/negative sentiment was considered insufficient.
Philosophy
Human opinion is multidimensional.
Understanding emotion is often as important as understanding agreement.
Entry 7 - Justifications
Feature
Supporting explanations for opinions.
Decision
Users may explain the reasoning behind their views.
Philosophy
Numbers tell us what people think.
Justifications help explain why.
Entry 8 - Opinion Lifecycle
Feature
Opinion expiry and renewal.
Decision
Opinions are not permanent.
Users must periodically renew them.
Philosophy
Public opinion changes.
The platform should reflect current views rather than preserve outdated assumptions indefinitely.
Architecture and Implementation
Entry 9 - Aggregation Engine
Feature
Automated rollups.
Technology
Serverless aggregation processes.
Decision
Opinions are aggregated at:
- Local
- Area
- Regional
levels.
Philosophy
The value of the platform lies not in individual opinions but in collective patterns.
Entry 10 - Event-Driven Processing
Feature
Asynchronous opinion processing and aggregation.
Technology
- AWS Lambda
- Amazon SQS
- DynamoDB
Decision
Opinion capture was separated from aggregation and reporting activities using message queues and serverless processing.
This allowed user interactions to remain responsive while heavier processing tasks were performed in the background.
Philosophy
Users should never have to wait for analytics.
Opinion capture and insight generation are related activities, but they do not need to occur simultaneously.
Costs are reduced if recalculated at point of entry, rather than requiring realtime reconstitution of the aggregate using full table scans.
Outcome
A scalable processing pipeline capable of supporting increasing participation volumes without redesigning the platform architecture.
Entry 11 - Data Model and Aggregation Storage
Feature
Hierarchical opinion storage and rollup architecture.
Technology
- DynamoDB
- Global Secondary Indexes
- Serverless aggregation
Decision
Rather than treating every opinion as an isolated record, the platform stores and aggregates information across multiple dimensions:
- Topic
- Geography
- Service
- Time
- Sentiment
This allows dashboards and reports to be generated rapidly without repeatedly recalculating large datasets.
Philosophy
The value of a dataset increases when relationships between records can be explored efficiently.
Entry 12 - Historical Data and Trend Analysis
Feature
Historical aggregation and time-based reporting.
Decision
The platform preserves aggregated historical information so that sentiment and participation can be compared across different periods.
Philosophy
A single snapshot tells us what people think today.
Historical analysis helps reveal:
- trends
- shifts in sentiment
- emerging issues
- declining concerns
Outcome
The foundation for longitudinal analysis and future trend reporting.
Visualisations
Entry 13 - Time Period Visualisation
Feature
Period-based dashboard views.
Components
- Last 7 Days
- Last 30 Days
- Last 90 Days
- Historical Views
Decision
Users should be able to understand not only the current state of opinion, but how it evolves over time.
Philosophy
Movement is often more interesting than position.
Changes in sentiment frequently reveal more than sentiment itself.
Entry 14 - Dashboard Navigation and Discovery
Feature
Interactive browsing components.
Components
- Geographic selectors
- Topic selectors
- Service selectors
- Drill-down navigation
- Search and discovery
Decision
Users should be able to navigate naturally between national, regional and local viewpoints.
Philosophy
Exploration often leads to insight.
Users should be encouraged to discover patterns rather than simply consume predefined reports.
Entry 15 - Sentiment Dashboard Framework
Feature
Unified dashboard architecture.
Components
- Sentiment cards
- Summary metrics
- Comparative views
- Participation indicators
Decision
Provide a consistent experience regardless of which dataset is being viewed.
Philosophy
Consistency reduces cognitive effort and encourages exploration.
Entry 16 - Topic Browser
Feature
Topic exploration interface.
Decision
Allow users to browse emerging and established topics through multiple routes rather than relying solely on search.
Philosophy
Important issues are not always the ones users initially seek.
Discovery should be supported alongside search.
Entry 17 - Service and Organisation Views
Feature
Service-centric reporting.
Decision
Enable opinions relating to services and organisations to be viewed independently from broader topics.
Philosophy
People often experience policy through services.
Understanding service sentiment provides a different perspective from understanding political sentiment.
Entry 18 - Word Clouds and Theme Extraction
Feature
Justification based word clouds to visualise frequently used keywords in user opinions, both on the topic and per opinion.
Technology
- Keyword extraction
- Frequency analysis
- Aggregated textual reporting
Philosophy
Structured sentiment explains how people feel.
Textual analysis helps explain why.
The combination of quantitative and qualitative information provides a richer picture than either approach alone.
Entry 19 - Sentiment Area Map
Feature
Geographic sentiment visualisation.
Decision
Display prevailing sentiment geographically across local areas.
Philosophy
Patterns are often easier to recognise spatially than numerically.
Outcome
One of the platform's most distinctive visualisations.
Reporting
Entry 20 - Reporting Framework
Feature
Formal report generation.
Decision
Create a bridge between dashboards and publishable outputs.
Philosophy
Insights become more valuable when they can be shared, archived and compared over time.
Entry 21 - Report Preview System
Feature
Public report previews.
Decision
Allow users to inspect report structure before purchasing.
Business Decision
Demonstrate value before requesting payment.
Entry 22 - Full Report Generation
Feature
Server-side report generation and storage.
Decision
Generate reusable report artefacts that can be accessed after purchase.
Philosophy
Reporting should be scalable and reproducible.
Entry 23 - Report Generation Architecture
Feature
Trusted aggregates and numbers
Technology
- Lambda-based report generation
- S3 storage
- On-demand document production
Decision
Reports are generated from the same underlying datasets used by the dashboards.
Philosophy
A single source of truth reduces inconsistency between visualisations and published reports.
Final Touches
Entry 24 - User Experience Refinement
Feature
Opinion submission redesign.
Components
- Simplified multi-step forms
- Breadcrumb navigation
- Reduced submission friction
- Contextual guidance
- Edit and review improvements
Decision
Lower the effort required to contribute opinions while maintaining data quality.
Philosophy
Participation is more likely when the process feels simple and approachable.
Entry 25 - Data Quality and Validation
Feature
Accurate and trustworthy aggregation numbers that add up and make sense across the various dashboards
Technology
- Additional Topics
- Aggregation reconciliation
- Rollup verification
- Historical consistency checks
- Dashboard/report alignment
Philosophy
Users must be able to trust that the same question produces the same answer regardless of where it is viewed.
Entry 26 - Deployment and Scalability
Feature
One of the questions raised during development was whether the platform could realistically be deployed beyond its initial Yorkshire and Humber trial area.
Rather than waiting until after launch to answer that question, we spent time reviewing how the platform could be configured, deployed and isolated across multiple environments and regions.
Technology
The platform now supports environment-aware deployment using a combination of:
- AWS Lambda
- DynamoDB
- SQS
- SES
Environment-specific configuration
Database tables, queues and functions are named using a consistent convention incorporating environment, country and region identifiers.
For example:
EO-DEV-ENG-YH EO-PROD-ENG-YH
This allows deployments to remain isolated whilst sharing the same application code.
- Deployment
- A deployment script was created to automate:
- Lambda packaging
- Lambda deployment
- IAM role creation
- Environment variable configuration
- DynamoDB permissions
- SQS permissions
- SES permissions
This significantly reduces the manual effort required to create and maintain environments.
Scalability
The objective was not to create dozens of deployments immediately, but to understand whether the architecture could support them.
By parameterising environments, countries and regions, the platform moves from:
One deployment
to:
One deployment model Many configurations
This provides flexibility for future expansion, whether through direct operation, regional rollout or potential licensing.
Observations
The most valuable outcome was not the creation of additional environments themselves, but the reduction of deployment effort and operational complexity.
Much of software development is not about solving a problem once. It is about understanding how many times the same problem may need to be solved in the future.
This work represents an investment in repeatability, maintainability and future growth, regardless of the eventual scale of the platform.
Commercialisation
Entry 27 - Monetisation Model
Feature
Introduction of paid reports and publication services.
Business Decision
Monetisation must not influence sentiment outcomes.
Philosophy
The integrity of the dataset is more important than short-term revenue.
Users cannot purchase influence over aggregated opinion.
Entry 28 - Minimal Advertising Strategy
Feature
Advertising framework.
Decision
Limit advertising exposure.
Philosophy
The platform seeks to capture attention for insight, not extract attention for profit.
Entry 29 - Pricing and Monetisation Framework
Feature
Establish a simple and transparent pricing model focused on utility rather than complexity.
Background
As development progressed, attention turned to a practical question faced by every platform:
How does the platform cover operating costs and generate revenue whilst remaining accessible to users?
A number of approaches were considered, including subscriptions, usage-based charging, advertising and premium account tiers.
The challenge was to identify a model that aligned with the objectives of the platform whilst remaining understandable to users.
Approach
The final model focuses on charging for value-added services rather than participation itself.
Users remain free to:
- Join the platform
- Submit opinions
- Browse the dashboard
- Explore public trends and sentiment
Revenue is generated through optional services, including:
- Report generation
- Publication rights
- Content submission and promotion
- Future API access
This approach allows participation to remain open whilst creating clear commercial value around insight, reporting and distribution.
In future, scope-based tiers have been planned, in order to make the prices more reflective of the geographical areas (and thereby participants) that any services are applicable to.
Principles
Several principles emerged during the design process:
Simplicity over complexity
A pricing model that requires explanation is often a pricing model that requires simplification.
Pay for outcomes, not access
The platform's value lies in the information it produces rather than the ability to submit opinions.
Avoid unnecessary barriers
The objective is to encourage participation and engagement rather than create obstacles to entry.
Observations
The exercise highlighted an important distinction between building a platform and building a business.
Technology creates capability.
Pricing determines whether that capability can be sustained.
Whilst pricing decisions may evolve over time, establishing an initial commercial framework represents an important milestone in transforming an idea into a viable product.
Entry 30 - Stripe Integration and Entitlements
Feature
Stripe payment integration and entitlement management.
Background
Earlier development work focused primarily on collecting, aggregating and presenting opinion data.
The introduction of paid services required a mechanism through which purchases could be processed securely and access rights granted automatically.
Rather than treating payments as a separate concern, the objective was to integrate commercial transactions into the existing platform workflow.
Technology
The implementation consists of:
- Stripe Checkout
- AWS Lambda
- API Gateway
- DynamoDB
- Webhook processing
Users initiate purchases directly from the platform.
A checkout session is created via AWS Lambda and the user is redirected to Stripe's hosted payment page.
Upon successful payment, Stripe generates a webhook event which is processed by the platform.
This event creates or updates the records required to grant access to purchased services.
Architecture
The solution separates responsibilities across multiple data stores:
Eligibility records determine whether a user is entitled to access a service.
Metadata records provide information about the service and its current state.
Content records store the underlying report, publication or submission data itself.
This separation simplifies administration whilst reducing coupling between payment processing and content generation.
Development
The implementation process highlighted a number of practical considerations including:
- Webhook processing
- Environment management
- Deployment automation
- Service entitlement creation
- Metadata synchronisation
- Redirect handling
Several deployment improvements were introduced during this work, including support for Lambda-specific environment configuration files.
Observations
The most satisfying aspect of this work was not the payment page itself, but the successful completion of the full transaction lifecycle:
- User purchase
- Payment processing
- Webhook execution
- Eligibility creation
- Service activation
For the first time, the platform demonstrated the ability to exchange value as well as information.
This represents a significant step from prototype towards product.
Entry 31 – Password Reset Functionality
Feature
Password reset and account recovery.
Background
During a final round of UI tidy-up and testing, I managed to forget my password and was therefore forced to use the password reset functionality.
This immediately revealed a problem.
The password reset workflow was no longer working correctly.
Investigation
Initial symptoms suggested a CORS issue. Browser errors indicated that requests were being blocked before reaching the endpoint.
As often happens with software development, the reported problem was not the actual problem.
Investigation moved through several possible causes including:
- CORS configuration
- API Gateway routing
- Lambda deployment
- Environment configuration
After a considerable amount of testing and diagnosis it became clear that the Lambda function was failing to start correctly.
Root Cause
A number of required environment properties had been removed during deployment.
The function therefore failed during startup before processing any requests.
Unfortunately, the browser surfaced this as a CORS error rather than a startup failure, which made diagnosis considerably more difficult than it should have been.
The issue was eventually traced back to missing configuration values and resolved by restoring the required environment properties.
Outcome
Password reset functionality was successfully restored and tested.
The experience also highlighted an important operational lesson.
Environment configuration is every bit as important as application code. A perfectly valid implementation cannot function if the required configuration is missing.
Observation
Many hours of debugging are spent solving the wrong problem.
The software reported a CORS issue.
The browser reported a CORS issue.
The actual issue was a startup failure caused by missing configuration.
The lesson was simple:
Do not wipe environment properties unless absolutely necessary. If you do, expect things to go wrong.
Development Complete
Entry 32 – Development Complete
Feature
I've run out of those.
Not that there aren't more features that could be added. There always are. But for the purposes of the MVP, we're good.
Observation
There comes a point in every project where adding another feature becomes less valuable than allowing other people to use what already exists. This week marked that transition for Exchange Opinions.
For the first time, the conversation has shifted away from architecture, integrations, and feature development towards deployment, validation, approvals, and user experience. The software is no longer the primary challenge. The next lessons will come from real users interacting with it.
Approach
We spent around forty-eight hours—or at least the equivalent of a part-time working week—building and deploying the production environment.
The environment was designed from the outset to support both scaling and the creation of new regions and deployments. That planning paid off. Although there were a few mishaps along the way, including accidentally deploying Yorkshire and Humberside as Humberside and Yorkshire with a degree of enthusiasm that AWS was only too happy to support, the process largely worked as intended.
Good planning, thinking ahead, and refusing to become too distracted by interesting side quests helped us reach this point.
A supportive partner to bounce ideas off, friends and family willing to test the platform, and—let me mention Gladys, my AI assistant from ChatGPT, for the first time—an AI companion along the way all played their part.
The result is that we now find ourselves waiting for Amazon to respond to a number of relatively routine approval requests.
Functionally, we're ready.
Operationally, we're close.
The remaining dependencies largely sit with external parties.
It's a strange feeling when that happens. For months, progress has been limited only by the number of hours available and the willingness to solve the next problem. Suddenly, the bottleneck becomes an international conglomerate reviewing forms and approval requests.
Whilst they have been considering whether I may send a handful of text messages and emails, I've deployed three environments in four days, fixed the occasional bug, scratched my head over the less occasional mistake, spent a considerable amount of time ignoring CORS warnings, improved deployment tooling, completed a number of technical necessities, and updated the aesthetics of the user interface whilst developing a much stronger understanding of React.
At least I hope they have comfortable chairs.
For now, Exchange Opinions is development complete.
The next chapter belongs to testing, validation, adoption, and whatever surprises real users decide to bring with them.
Publicity and Release
Entry 33 – Chasing the Sunrise
Feature
Photography.
At least, that was the excuse.
Observation
With the development work largely complete and the production environment waiting on a handful of external approvals, attention turned briefly away from software and towards the region that the platform was built to serve.
The original objective was simple enough: collect some photographs for use on the website. Rather than rely on stock imagery, it seemed more appropriate to capture some images of Yorkshire and the Humber ourselves.
What followed was a 4:30am start and a short tour of the Humber Bridge and surrounding countryside in search of a sunrise.
The weather, unusually for Yorkshire, cooperated.
Approach
The exercise unexpectedly served three different purposes.
The first was practical. We needed imagery for the site. The photographs will eventually form part of a carousel and help reinforce the identity of the Yorkshire and Humber pilot region.
The second was personal. Spending time together watching the sun rise over the Humber proved considerably more enjoyable than staring at deployment logs and waiting for emails from Amazon.
The third was routine. Getting up before dawn requires intent. It is difficult to spend months thinking about new beginnings whilst maintaining exactly the same habits. Sometimes the smallest changes are the most symbolic.
As the sun appeared over the horizon, I remember suggesting the words:
“New start.”
At the time it felt like a comment about the morning.
In hindsight it may have been about something else.
Reflection
The photographs themselves turned out well. The Humber Bridge stood against a gradually brightening sky. The estuary reflected the first light of the day. The countryside revealed itself slowly beneath the sunrise.
Yet the images were only part of the story.
For much of the last year, life has been dominated by uncertainty, recovery, learning and rebuilding. Exchange Opinions began as a technical project but gradually became something more than that. It provided structure, creativity, purpose and an opportunity to think about ideas that had been sitting quietly in the background for years.
Watching the sunrise felt strangely appropriate.
The platform is not yet proven. The users have not yet arrived in significant numbers. The reports have not yet been purchased. The larger questions remain unanswered.
But the software is built.
The pilot is ready.
The day has begun.
And sometimes that is enough.
Outcome
A collection of photographs.
A memorable morning.
And perhaps a reminder that progress is not always measured in features delivered, bugs fixed or environments deployed.
Sometimes progress is simply standing still for a moment and recognising that a new chapter has already started.
Entry 34 - UAT
By the time the Yorkshire and Humber pilot reached User Acceptance Testing, the technical foundations of the platform were largely in place. Opinions could be submitted, aggregated and displayed. Reports could be generated. Publications could be purchased and viewed. Payments were working, data was flowing and the platform had begun to resemble the vision that had existed largely on paper for many years.
The challenge now was not whether the software worked, but whether people could use it.
One of the more interesting aspects of the testing process was that the test group was never formally assembled. Instead, it evolved naturally from the people around me. Friends, family and former colleagues all contributed in different ways, often without realising that they were performing different testing roles.
The Experienced Operator
As both designer and developer of the platform, I naturally became the primary tester.
This had advantages and disadvantages. I understood how the system was intended to operate and could quickly identify defects, trace them through the codebase and implement fixes. However, familiarity can also be dangerous. Once a developer knows how a system works, it becomes increasingly difficult to see it through the eyes of a new user.
Many of the issues discovered by others were not technical failures at all. They were assumptions that I had unknowingly made during development.
The Document Reviewer
My brother approached testing with a level of structure that would have impressed many professional testing teams.
What began as a few observations quickly became a multi-page document containing comments, suggestions, questions and bug reports. Not every item turned out to be a genuine issue and some required explanation of the underlying design. Nevertheless, the exercise was invaluable because it forced me to justify decisions that had previously existed only in my own head.
A surprising number of improvements originated from that document.
The Systems Thinker
Steve's feedback was often less concerned with individual screens or specific bugs and more focused on the overall structure of the platform.
He would frequently ask questions about how different components interacted, how information flowed through the system and how users might behave in unexpected situations. Many discussions were less about software and more about communication, governance and social dynamics.
His feedback often challenged assumptions that I had not realised I was making.
The Experienced User
Adam was a former colleague and an experienced technology professional, but unlike many of those involved in the development discussions, he had very little prior knowledge of Exchange Opinions itself.
This made him a particularly useful tester. He approached the platform with the confidence of an experienced user whilst still encountering it largely for the first time.
Many of the key user journeys were exercised during testing, including registration, opinion submission, navigation and some of the paid functionality. Although he occasionally required clarification regarding the purpose of certain features, he was generally able to navigate the system successfully and provide constructive feedback throughout the process.
What made this particularly encouraging was that it suggested the platform was becoming understandable without extensive explanation. The underlying concepts were not entirely self-evident, but with a modest amount of guidance through the About and How To sections, experienced users appeared capable of understanding both the mechanics of the system and its intended purpose.
Perhaps more importantly, Adam approached the exercise with good humour and patience, willingly testing functionality that was still evolving and occasionally unfinished. That willingness to engage with an imperfect system provided valuable reassurance that the platform could be learned and used by people who had not been involved in its development.
In many ways, he represented the first genuinely independent experienced operator. His participation helped demonstrate that the platform was beginning to move beyond something understood only by its creator and towards something that other people could learn and use for themselves.
The Novice Operator
Big John represented perhaps the most important category of tester: somebody with no prior knowledge of the platform.
Unlike developers and analysts, novice users rarely follow expected paths. They click unexpected buttons, ask unusual questions and frequently ignore instructions entirely.
The resulting discussions were often unstructured, occasionally chaotic and consistently useful. What appeared obvious to me was often not obvious to somebody encountering the platform for the first time.
Those conversations helped identify areas where the user experience could be simplified.
The First Impression Test
My Aunt and Uncle provided another valuable lesson.
Something did not work correctly during their initial experience with the platform and, despite assurances that it could be fixed, they never attempted to use it again.
This was perhaps one of the most important findings of the entire testing exercise.
Software developers are often willing to forgive defects because they understand how software evolves. Most users are not. First impressions matter. If something appears broken, many people simply move on.
The lesson was clear: reliability is often more important than sophistication.
The Encouraging Beginner
My father's contribution was perhaps the most reassuring.
Unlike many of the others, he had no prior involvement in the design or implementation of the platform. He approached it as an ordinary user.
His feedback was unstructured but timely. More importantly, he continued using the platform over a period of weeks and experienced its gradual development firsthand. Features appeared, bugs disappeared and the overall experience improved.
The fact that he was able to understand the concept, navigate the platform and contribute opinions without extensive assistance gave me confidence that the idea itself could be understood by ordinary users.
In many ways, this was one of the most encouraging outcomes of the entire testing process.
The Interested Observer
Charlotte's contribution began much like that of many others: by identifying bugs, suggesting improvements and providing feedback on the overall user experience.
What made her involvement different was that she gradually became interested not only in how the platform functioned, but also in how it was presented.
As development progressed, discussions increasingly moved beyond software defects and into areas such as design, presentation and visual identity. Homepage imagery, branding, user experience and the overall feel of the platform became subjects of conversation alongside the technical implementation.
This perspective proved particularly valuable because it came from somebody who was neither a software engineer nor directly involved in the development process. Questions that developers often overlook were raised naturally, and assumptions that had become invisible to me after months of development were frequently challenged.
Perhaps most importantly, her interest provided an external measure of whether the project was becoming understandable to somebody outside the technology industry. The fact that she continued to take an interest as the platform evolved was encouraging in its own right.
Not every contribution to a software project comes in the form of code, specifications or bug reports. Sometimes the most useful contribution is simply taking enough interest to ask, "Why does it work like that?"
Different People Break Software Differently
One of the most interesting observations from User Acceptance Testing was that every participant effectively tested a different system.
- Developers looked for defects.
- Analysts looked for inconsistencies.
- Friends questioned assumptions.
- Family members tested usability.
- Novice users challenged expectations.
- Experienced users exercised functionality.
Together they revealed issues that no individual tester would have discovered alone.
By the end of the process, the platform was undoubtedly more stable, more understandable and more useful than it had been at the beginning. Not because any single person found every problem, but because each participant approached the system from a different perspective.
In a platform designed to collect viewpoints, it was perhaps fitting that the testing process itself depended upon a diversity of viewpoints.
Entry 35 - AWS Activate Approval
Today brought a small but welcome milestone for Exchange Opinions.
Following an application to the AWS Activate programme, I received confirmation that the project had been awarded $1,000 in AWS credits, available until 2028.
At first glance, the amount itself might not seem particularly significant. In the world of technology startups, funding announcements often involve much larger figures. However, for a platform built deliberately around a serverless architecture and cost-efficient cloud services, the practical value of these credits is considerable.
More importantly, it represented something else.
Validation.
Not validation that the platform will succeed, attract users or become commercially viable. Nobody can provide those assurances. Rather, validation that an established technology provider looked at the project and concluded that it was sufficiently credible, sufficiently real and sufficiently developed to warrant support through their startup programme.
The timing was particularly welcome.
Only a few months ago I was questioning whether I still possessed the motivation, focus and technical capability required to build a modern software platform. Since then, Exchange Opinions has progressed from a collection of ideas and some old experimental code into a live public beta environment supporting user registration, opinion collection, aggregation, reporting, publishing and payment services.
The approval does not fundamentally change the direction of the project.
Yorkshire and Humber remains the pilot region. The objective remains the same: attract users, gather feedback, understand behaviour and determine whether the underlying concept provides value.
What the credits do provide is breathing room.
Rather than worrying about infrastructure costs as the platform evolves, I can spend more time focusing on user experience, content, communication and understanding whether people genuinely find value in the service.
Like many milestones during this project, the significance was not financial.
It was psychological.
Another small signal amongst a great deal of noise that perhaps the project is moving in the right direction.
Entry 36 – Going Live
There are moments during the development of a software project when it becomes clear that the work is changing in nature. The early months are often spent designing, experimenting, building and occasionally rebuilding. Features appear, disappear and reappear in different forms. Ideas evolve as understanding improves. The application remains firmly within the realm of possibility.
At some point, however, possibility becomes reality.
This week marked the first live deployment of Exchange Opinions.
From a technical perspective, the deployment itself was not entirely straightforward. There were the inevitable production issues that only become visible once an application is released into a real environment. Permissions that appeared correct in development required further attention in production. API Gateway integrations, Lambda permissions, queue triggers, deployment scripts and configuration settings all needed careful review.
As is often the case with cloud-native systems, the final stages were not dominated by software development but by infrastructure, security and deployment concerns. The application itself was largely complete; the challenge was ensuring that all of the supporting components worked together consistently in a live environment.
Fortunately, this is also where the benefits of automation become most apparent. Over the last few months I have gradually developed deployment scripts capable of provisioning and updating large parts of the environment automatically. What initially required numerous manual steps is increasingly becoming a repeatable process. Whilst there is still work to do, the foundations are now in place for future regional deployments.
Perhaps more important than the deployment itself has been the feedback process.
A small group of family members, friends and former colleagues have been exploring the application and providing suggestions. Some of these identified genuine defects. Others highlighted areas where the user experience could be improved. A few challenged assumptions that had existed since the earliest design stages.
One particular question stood out:
"What happened to the thing I wrote?"
It is a deceptively simple observation. Exchange Opinions originally focused on aggregate sentiment and visualisation. Users could contribute opinions and justifications, but much of the emphasis was placed on the aggregate outcome rather than the individual explanation.
The question prompted the introduction of a new Public Views section, allowing users to optionally share their written justifications publicly. This provides a bridge between individual contributions and collective insight. It also demonstrates one of the strengths of releasing software early; users frequently identify opportunities that the developer has overlooked.
Another milestone occurred shortly after deployment.
The first public contribution was posted on the topic of Exchange Opinions itself.
The sentiment selected was "love".
The justification explained the origins of the project, the role of family and friends in testing ideas, the use of modern cloud technologies and artificial intelligence during development, and the philosophical inspiration drawn from Adam Smith's Theory of Moral Sentiments.
Whilst the post itself was relatively modest, it represented something more significant. For the first time, the platform was being used for its intended purpose. It was no longer simply a software project; it had become a place where opinions could be expressed, shared and explored.
Looking back, it is difficult to ignore the personal journey that accompanied the technical one.
Exchange Opinions began during a period of recovery from burnout. What started as a technical exercise gradually became an opportunity to reconnect with the aspects of software development that I had always enjoyed most: creativity, experimentation, problem solving and the freedom to build something from first principles.
The application remains in its pilot phase. There are still features to refine, feedback to incorporate and services to test. Email and SMS capabilities are being finalised, user experience improvements continue to emerge and additional content is being prepared for launch.
Nevertheless, the transition from development environment to live deployment marks an important milestone.
The Yorkshire and Humber pilot is now live.
The next challenge is no longer whether the system can be built.
The next challenge is discovering whether people find value in using it.
Entry 37 – The First Post
Every platform begins empty.
Before the first opinion is submitted, before the first discussion begins and before the first contribution is made, a platform is little more than a collection of software components waiting for a purpose.
Exchange Opinions was no different.
For years the concept had existed as conversations, notes, diagrams, prototypes and eventually software. There had been discussions with friends, colleagues and family members. There had been debates about philosophy, communication, governance, economics and technology. There had been countless hours spent designing, building, testing and refining.
Yet despite all of this effort, the platform remained fundamentally empty.
That changed with the first post.
The first topic submitted to the platform was appropriately simple:
Exchange Opinions
It seemed fitting that the platform's first opinion should be about itself.
The accompanying public view described the project's origins, the circumstances that had led to its development and some of the ideas that had influenced its creation. It was not intended as marketing material or a sales pitch. Instead, it served as an explanation of why the platform existed and what it was attempting to achieve.
In some ways, it was a statement of intent, in others a statement of satisfaction.
Shortly afterwards, the first submission was published.
Unlike the public view, which represented an individual's perspective, the submission provided supporting material for anyone interested in understanding the project in greater detail. The chosen submission was the Development Journal itself: a record of the platform's evolution from concept through implementation.
Publishing that submission required purchasing the service exactly as any future user would.
The transaction cost £10.
Objectively, this was little more than moving money from one pocket to another. Yet the experience proved surprisingly satisfying. For the first time, the complete publishing workflow had been exercised end-to-end using genuine content.
- A topic existed.
- A public view existed.
- A submission existed.
- The payment had been processed.
- The entitlement had been created.
- The content could be viewed.
- The entire chain functioned as intended.
The amount itself was insignificant. The symbolism was not.
For the first time, Exchange Opinions contained something real.
The significance of the moment was not that the first post was particularly important, nor that many people would immediately read it. The significance was that the platform had ceased to be empty.
Every subsequent contribution would build upon that foundation.
Every future opinion, public view, submission, report and discussion would trace its origins back to a single topic and a single post.
The first one.
Looking back, it is unlikely that anybody will remember precisely what was written. What will remain important is that somebody was willing to write it.
Fortunately, that somebody happened to be me.