Imran —> Diverse Experience
Building the four-step DAWN product vertical
Prometheus is AmadeusWeb's IT Product and Services wing.
Its product vertical takes an organisation from being understood and discovered to operating within a connected, secure, capable digital ecosystem.
The four steps are Marketing, Federation, Security, and CRM / ERP.
They are not disconnected service labels.
They describe a progression: communicate the mission, connect it to others, protect the people and work involved, and support the relationships and operations that sustain delivery.
I am Imran Ali Namazi, the technologist who created AmadeusWeb Spring and leads Prometheus.
I bring 26 years of building systems, from hobbyist experiments to enterprise-grade applications and frameworks.
I have worked across software engineering, architecture, technical leadership, mentoring, product delivery, content systems, and independent platform building.
I have also remained a hands-on maker throughout that journey.
That combination is why I am exceptionally well placed to lead this product vertical: I can understand a mission, shape its digital presence, design the systems behind it, and teach its people how to keep building.
This is not a claim that one person should personally implement every specialised capability.
It is a statement of technical range, product judgment, practical delivery, and the ability to assemble the right solution—built on Spring, integrated with suitable tools, or delivered with trusted specialists where required.
A product leader who has built at every level
My experience begins before my professional career.
At eleven, I learned BASIC on a Spectrum.
At fourteen, I was introduced to WordStar and paper-based ERP through a family business.
From fifteen through my early twenties, I co-designed electronics projects from end to end with the help of an uncle.
From seventeen onward, I built Windows applications and explored how software could help people find, organise, and act on information.
One early application used MS Access and supported daily-labourer searches through tree-based criteria, SQL building, saved searches, and HTML rendering.
That was not just code practice.
It was an early lesson in turning a real-world need into an understandable workflow.
I graduated in Electronics Engineering at twenty-two.
By then, I was already moving between hardware thinking, software implementation, and questions about how technology could serve wider human needs.
For 26 years, I have continued that movement between experimentation and production.
I have worked as a hobbyist, freelancer, developer, framework builder, senior developer, tech lead, architect, mentor, and founder of a web platform.
I have built for individual projects, small teams, global products, internal business operations, and enterprise contexts.
Each environment taught me a different discipline.
The hobbyist's discipline is curiosity and resourcefulness.
The enterprise discipline is reliability, maintainability, coordination, and accountability.
The product discipline is to connect technical decisions to a real user and a sustainable outcome.
Prometheus needs all three.
The product vertical: four steps, one coherent practice
The complete product outline is at Prometheus Product.
The following is how my experience maps to each of its four stages.
1. Marketing: make the mission clear and discoverable
Marketing begins with understanding.
An organisation must be able to explain who it is, what it offers, whom it serves, and what action a visitor can take.
My work across web applications, global sales pages, publishing systems, content architecture, and client projects gives me a builder's view of this journey.
At Photon, I was lead developer on the Englishtown sales-page work.
The pages were unified and revamped across global markets.
The work included redesigning pages, fixing defects, creating dynamic pages, setting up environments, onboarding, and supporting the release process.
This is direct experience with the practical realities behind a marketing presence: multiple audiences, consistent presentation, dynamic content, and dependable releases.
I later built websites and publishing tools through freelance work.
Those projects included sports communities, timesheet applications, custom frameworks, business-to-business commerce, booking workflows, publishing, and WordPress extensions.
At BORN Group, I worked on product advertising and a catalog migration.
I assessed alternatives, ported selected features, benchmarked frameworks, understood a Magento schema, and built a WinForms tool to prepare catalog data for import.
These are not abstract marketing credentials.
They are the technical foundations that make offers discoverable, pages maintainable, content portable, and customer journeys implementable.
I know that a landing page is not the whole marketing system.
Content structure, metadata, audience intent, a clear next step, and operational follow-through matter just as much.
Spring supports this approach with file-based pages, Markdown, HTML, PHP, sheets, metadata, folder-derived navigation, media, and reusable templates.
The aim is not to force every organisation into one campaign style.
The aim is to give each mission a clear, owned home and a path from interest to meaningful action.
2. Federation: connect independent homes and capabilities
Federation demands more than links between websites.
It requires sound architecture, clearly bounded responsibilities, interoperability, discoverability, and respect for each participant's autonomy.
My career has repeatedly involved building frameworks that let different components work together without making every project identical.
At Applied Development, I worked on ERP, financial, HR/legal, service-management, documentation, and internal workflow projects.
I led development on a TopPower ERP framework with object-relational and UI mappers.
I co-architected framework capabilities and built a legacy code explorer to track conversion work.
That experience taught me how to make a common foundation useful across distinct operational contexts.
At Sulekha, I wrote architecture and infrastructure layers for a mobile consumer-to-service-provider matching platform.
The stack included VueJS, TypeScript, and ASP.NET Core.
I also began architecting and proving a scalable Communications Center that integrated providers such as WhatsApp and Google My Business.
That work required thinking about multiple services, multiple channels, and a coherent experience across them.
At BORN Group, I worked across .NET and PHP during a product migration.
I ported selected features to different PHP frameworks and built statistics modules to compare their suitability.
I was the developer who knew both languages and helped the existing team learn PHP.
That is practical federation work at the engineering level: preserving useful capabilities while changing boundaries and connecting different technologies.
Spring applies this mindset to the web.
Each site can have its own domain, content, identity, and purpose.
Folder-based structure makes navigation and relationships visible.
Shared media can be served through a CDN without bloating each site's own content.
Public sites can publish from their own repositories, while the network connects them through human-readable links and shared conventions.
Federation should strengthen each member's home, not absorb it into an opaque central platform.
My framework and integration experience gives me the judgment to design for that balance.
3. Security: make responsibility part of the design
Security is not a decorative feature or a slogan.
It is a set of choices about data, access, deployment, maintenance, recovery, and who is accountable.
I have worked on an intranet information-security application, banking backends, enterprise systems, internal tools, and global web products.
At Constient, I worked on the backend of a banking site and identified performance bottlenecks.
I mentored teams, worked with legacy code, and built a ticket generator with barcode printing.
At Applied Development, my work included HR/legal systems, an intranet application, and a custom code-coverage analysis tool.
In other roles, I have handled code reviews, troubleshooting, release processes, deployment environments, and technical standards.
These experiences have taught me to treat security as an operational responsibility.
A system must be understood by the people who maintain it.
Its data boundaries must be deliberate.
Its deployment and recovery practices must be known, not assumed.
Its risks must be discussed in the context of how it is actually used.
Spring takes a deliberately lightweight approach to publishing.
Content is stored as files and can be backed up with Git.
Work can be developed offline, reviewed locally, and deployed through a controlled upload process.
The framework avoids requiring a database-backed login for ordinary public publishing.
That reduces entire categories of operational complexity for sites that do not need those capabilities.
It does not mean every business workflow has no security needs.
Private records, authenticated functions, payment flows, and external integrations require appropriate safeguards and careful design.
My experience helps distinguish where simpler architecture is a security advantage and where stronger controls are necessary.
4. CRM / ERP: connect relationships to delivery and operations
CRM and ERP systems are where promises meet real work.
They must support the way an organisation receives enquiries, manages relationships, plans delivery, records operations, and learns from outcomes.
I have spent years building in and around these systems.
At Applied Development, I contributed to ERP applications and loan-application and servicing frameworks.
I built custom object-relational mappers and UI frameworks for Windows applications.
I delivered service-management, financial, HR/legal, timesheet, and candidate-processing workflows.
At Photon, I worked on application and database concerns for a large international learning product.
At Headstream, I led a small team across frontend and backend technologies and delivered implementations as a one-person team during a transition.
At Sulekha, I worked on a matching platform that connected consumers and service providers.
I have also built reporting systems.
In 2018, I wrote a generic flexible reporting engine in C#.
At Headstream, I wrote a robust and generic reporting framework.
At Sulekha, I documented processes, checklists, plans, requirements, work breakdown structures, technical specifications, features, and bugs in an organised Git repository.
That combination matters to CRM and ERP.
I understand that a contact record is not useful in isolation.
It must connect to an agreed next step, a responsible person, an opportunity or service, and a record of what happened.
An enquiry can lead to a conversation.
A conversation can become an agreement.
An agreement can create a project, service task, or operational commitment.
Delivery can then inform follow-up, reporting, and improvement.
Spring provides a flexible web and content foundation for the public-facing parts of this path.
Where an organisation needs private CRM or ERP workflows, the right answer may be a purpose-built extension, a specialist product, a documented integration, or a staged combination.
I have built custom business frameworks and I know when to reuse an established tool.
The objective is a coherent workflow, not rebuilding every commodity system for its own sake.
AmadeusWeb Spring: a treasure chest of practical possibilities
Spring is not an off-the-shelf promise that every imaginable application is already complete.
It is a mature, extensible foundation for building a wide range of web experiences and digital workflows.
It brings together ordinary, inspectable technologies with a proprietary framework that stitches the site experience together.
The platform supports Markdown, HTML, PHP, TSV sheets, rich pages, forms, decks, email templates, AI chat exports, images, PDFs, and embedded media.
The exact combination depends on the mission and the job to be done.
Content and code can be organised in folders that express the site's structure.
Top-level sections can stay out of URLs while nodes, subnodes, pages, and contextual menus provide meaningful navigation.
The menu can be derived by reading the folders and files.
Article sheets can feed landing pages while each article carries its own metadata.
This keeps content and presentation inspectable and maintainable.
PHP, TSV, and HTML allow rich pages to separate content from layout in different ways.
Themes and reusable templates help produce consistent sites.
Media can live in site folders or in shared CDN locations.
This gives teams room to build without allowing every website to become an unstructured pile of assets.
Git provides history and a practical backup path for file-based content.
Teams can develop offline and review work before publishing it.
VS Code, TortoiseGit, and project-management practices give collaborators tools they can learn and use directly.
The public repository model makes the work transparent for projects that choose public publishing.
Structured email templates let a visitor open an email draft rather than sending information through a hidden form-processing service.
The platform can use a simple FTP deployment path for sites whose requirements suit it.
More complex requirements can be assessed and handled through appropriate code, integrations, infrastructure, or specialist services.
This is the treasure of Spring: not a claim that one feature fits every case, but a versatile set of building blocks that can be combined around the real requirement.
A marketing site, knowledge base, directory, service catalogue, publishing workflow, documentation hub, or mission network can start from the same comprehensible foundation.
The site can grow iteratively as the organisation learns.
That is why I describe a website as a three-year outline of content, activities, and areas of work, built step by step.
The principle is captured in my own words:
“So a website is really a 3 year outline of what sorts of content is needed, to support which areas and activities and then built iteratively.”
I build the system and build the team's capability
My role is not limited to writing code.
I clarify requirements with clients.
I break work into deliverable tasks.
I design architecture, prototype, code core features, review implementation, and mentor developers.
I communicate across technical and non-technical roles.
I push back when scope threatens quality or long-term interests.
I adapt to new technologies when the problem calls for them.
I have led teams, trained colleagues, interviewed candidates, troubleshot production concerns, and established practices.
One enduring statement of my approach is:
“Im Imran, I train teams to build robust web ecosystems for themselves.”
That is central to Prometheus.
Clients should not be left dependent on a mysterious system they cannot understand.
I teach teams to work with their own content, tools, repositories, and operating practices.
I explain the trade-offs behind the architecture.
I help members become more capable, not merely more subscribed.
My career includes repeated examples of this approach.
At Applied Development, I handled practices and training alongside delivery.
At Sulekha, I trained teammates in sound coding practices, attention to detail, documentation, and communication.
At Headstream, I mentored developers and helped teams through technical transitions.
At BORN Group, I helped an existing team pick up PHP because I could work across both languages.
This is how a product becomes sustainable: people understand it, own their part in it, and can continue improving it.
Evidence from the work
The credentials here are grounded in the documented record in The Technologist.
The professional history spans more than a dozen years of full-time and contract roles, alongside longer-running freelance work and personal platform development.
At Englishtown, a global English-learning website with millions of students, I rebuilt worldwide sales pages in my first year at the company.
In my second year, I helped bring its community application to life.
That community supported profiles, friend search, messaging, chat, administration, contact importing, and a high-traffic message centre.
At Applied Development, I worked for nearly five years across ERP, loan application and servicing frameworks, Windows applications, web applications, and internal tooling.
I helped build custom frameworks rather than treating each application as an isolated codebase.
I have built reporting engines, code explorers, migration trackers, log viewers, Visual Studio extensions, installers, and UI frameworks.
Those tools helped other people deliver and maintain software.
At Headstream, I joined during a transition and handled implementations as a one-person team while exceeding client expectations, as described in a colleague's recommendation.
I led a compact team working across frontend and backend frameworks.
At Sulekha, I brought architecture and infrastructure thinking to a mobile matching platform and communications centre.
Across freelance work, I built and maintained PHP sites, frameworks, publishing projects, e-commerce work, booking experiences, and Windows utilities.
Alongside client work, I created AmadeusWeb Spring.
The Spring codebase is the culmination of years spent building applications, frameworks, and content systems.
I have not only advised on a platform; I have spent years making one.
The combination of breadth and continuity is important.
I can work from first principles when the problem is genuinely novel.
I can also recognise when a stable tool or established service is the wiser choice.
What colleagues and my own record say
My technologist profile describes the skills I bring to Prometheus in direct terms:
“Understanding and clarifying requirements of clients.”
“Project planning and task breakup / delegation.”
“Coding architectural needs and prototyping.”
“Writing elegant sophisticated code, setting up code standards and reviewing them.”
“Pushing back on scope keeping quality and long term interests in mind.”
These are not separate from delivery.
They are the practices that turn a broad ambition into a plan a team can build and maintain.
My Applied Development record includes a colleague's reflection, written eight years after we worked together:
“Imran is the best colleague I've ever had.”
“He is one of the most dedicated professionals I've worked with, and he is always willing to lend a helping hand when you need it.”
“His experience as a senior developer is extensive, and it aided our team in developing more efficient solutions for various projects.”
The same colleague said:
“His contribution is valuable on the side, and I highly recommend Imran and would welcome the opportunity to work with him again.”
At Headstream, my manager described my work during an organisational transition:
“Handled few implementations as a one man team and delivered exceeding the client expectations.”
He also called me:
“A very strong troubleshooter”
and recognised my ability to:
“come up with innovative solutions on the fly.”
His recommendation concludes:
“An amazing asset for any organization looking for a technical leader.”
At Sulekha, the record describes the work I bring to complex product environments:
“Wrote architecture and infrastructure layers for a mobile consumer - service provider matching platform”
“Began architecting and proved the concept of a scalable and comprehensive Communications Center”
“Trained teammates on sound coding practices and an attention to detail, documentation and communication.”
These statements reinforce the same pattern across independent roles.
I take ownership.
I find a path through complexity.
I build practical systems and frameworks.
I help the people around me become stronger.
I communicate clearly about what should be built and why.
A relentless, impassioned work ethic
My work ethic is not a marketing adjective detached from evidence.
It is visible in the length and variety of the work I have chosen to carry.
I remained a programmer and electronics hobbyist while studying and building my career.
I freelanced for more than fourteen years across software, web, publishing, and utility projects.
I worked through a succession of roles while continuing to learn new languages, frameworks, platforms, and architectural approaches.
I created AmadeusWeb and continued developing it as a long-term product.
For twelve years, I pursued a demanding personal mission that required writing, curating, publishing, and building a platform to hold the work.
I have described that period as being “possessed by the idea.”
The phrase captures the intensity, but the result was sustained work across technology and content.
My approach is hands-on.
I do not ask a team to follow a practice I am unwilling to understand.
I do not treat documentation as an afterthought.
I do not mistake novelty for progress.
I care about the details that determine whether the system can be used, maintained, explained, and improved.
My standards are high because the work matters.
My persistence is matched by a willingness to learn, revise, and course-correct.
Why I am the right person to lead this job
Prometheus needs leadership that can connect strategic intent to working systems.
I have done that across commercial software, internal tools, public websites, content systems, and an independently developed platform.
Prometheus needs a product builder who can see all four stages as one journey.
I understand how discoverability leads to relationships, how federation depends on architecture and trust, how security depends on operational reality, and how CRM / ERP must support actual delivery.
Prometheus needs technical range without technology worship.
I have worked across .NET, C#, SQL Server, Entity Framework, PHP, JavaScript, VueJS, TypeScript, VB6, WinForms, WPF, web APIs, databases, and content platforms.
I have learned new frameworks under delivery pressure and assessed alternatives before committing to them.
Prometheus needs someone who can build foundational technology.
I have built frameworks, mappers, reporting engines, workflow systems, developer tools, and AmadeusWeb Spring itself.
Prometheus needs someone who can help other people become capable.
I have mentored developers, trained teams, documented engineering practices, and designed Spring around direct understanding and participation.
Prometheus needs someone who can make technology serve a mission.
My long-running work has joined software with publishing, learning, community, health, and social purpose.
I bring the persistence to carry an idea through architecture, implementation, content, deployment, and real use.
I bring the judgment to keep the solution proportionate.
I bring the conviction to build for ownership, transparency, and long-term usefulness.
That is why I am the best person to lead the Prometheus product vertical.
A confident commitment, grounded in engineering
I can take a technology requirement and work out how to meet it.
I begin by understanding the mission, users, constraints, data, and operating context.
I then choose the simplest sound path through Spring's building blocks, custom development, integration with specialist products, or a combination of them.
The range of possibilities available through AmadeusWeb Spring is substantial.
Its file-based model, content formats, templates, PHP foundation, navigation conventions, media handling, Git workflow, and deployment options cover a wide spectrum of web and publishing needs.
Where a requirement extends beyond the platform's present capabilities, I can assess the gap and define a responsible extension or integration.
Where a requirement calls for specialist expertise, I can define the architecture and work with the appropriate people.
No serious technologist should promise that every conceivable need is already solved by one framework.
I do affirm that Prometheus can handle the technology needs of its product vertical by applying the full range of Spring's possibilities, my 26 years of experience, and sound engineering judgment.
The promise is not a magic button.
It is a capable product practice led by a technologist who has repeatedly built the frameworks, applications, tools, and teams needed to move difficult work forward.
| Name | About | Tags | Size |
|---|---|---|---|
| Diverse Experience | No About Set | #No Tags Set | 25.92 KB |